[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Bug #1134
On Thu, 2008-07-31 at 23:05 +0200, Kern Sibbald wrote:
> On Thursday 31 July 2008 22:27:11 Scott Barninger wrote:
> > Hello Kern,
> > It is true this is a packaging issue and it is true that bconsole in the
> > project rpm packages can not be executed by a script since it's
> > permissions are set root,root. I'm not sure I call that a bug. Should a
> > script be able to execute the console?
> I don't think it is a bug either, but it is something I never really thought
> about. If you do a make install running as root, then Bacula can execute a
> script which can call bconsole, and it can be very useful for certain
Which of course is why we do not build packages as root and use the
setattrib macro to specify the user:group desired. We are controlling
the ownership of files in some cases, taking the default in others, but
not messing with permissions set by the Makefile in any case, except for
a few broken things that may or may not have been addressed since they
were added (see the spec file comment # now clean up permissions that
are left broken by the install).
> I am not 100% sure about the security implications, which is one of the
> reasons I asked you to "take a look at it" rather than "please fix it". My
> basic instinct is to not change anything, because I am nervous about having a
> non-restricted console executable by anyone other than root unless the
> SysAdmin explicitly permits it. That way, we ship something that we know
> doesn't have an unexpected security problem.
Exactly why I am questioning it. My personal opinion, in the absence of
more informed opinion, would be to not change a thing and close the bug
report with the suggestion to the user to manually change the ownership
of bconsole if really desired. The bacula group already exists in the
packages so a chown root.bacula by the user would do the trick.
On my own personal server, if this would help me I would do it. If I
were administering a public company server, I would not do it. IMHO
> I've copied the bacula-users list as Jason suggested, so that if there are any
> good arguments for changing the current behavior, we can take them into
> Best regards,
> =========== Excerpt of bug #1134 ==========
> 0001134: wrong rights on /usr/sbin/bconsole: can't use it in RunBeforeJob /
> % ls -l /usr/sbin/bconsole
> -rwxr-xr-- 1 root root 245328 Jul 23 13:58 /usr/sbin/bconsole
> So bacula user can't run this binary, for instance via script shell(s) in
> RunBeforeJob or RunAfterJob.
> This binary should have bacula as group and be executable by this group.
> Steps To Reproduce
> - download and install bacula-2.4.1-1.src.rpm
> - build binary RPM:
> % % rpmbuild -bb --define "build_centos5 1" \
> --define "build_mysql5 1" \
> --define "build_python 1" \
> > On Thu, 2008-07-31 at 19:00 +0200, Kern Sibbald wrote:
> > > Hello Scott,
> > >
> > > I hope things are going well for you. Would you take a look at bug
> > > #1134. I think this is a packaging issue. The report says that bconsole
> > > should be executable by a runscript that is executed by Bacula, but it
> > > does not have permission.
> > >
> > > Regards,
> > >
> > > Kern
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.