On Friday 01 April 2011 20:46:17 Luca Berra wrote:
> On Fri, Apr 01, 2011 at 06:24:57PM +0200, Kern Sibbald wrote:
> >On Friday 01 April 2011 16:24:34 Luca Berra wrote:
> >> On Wed, Mar 30, 2011 at 03:00:07PM +0200, Luca Berra wrote:
> >> >>Philipp,
> >> >>
> >> >>I concur with Eric.  The change you proposed will not work.  One
> >> >> cannot fix the problem at installation time.  It must be fixed when
> >> >> Bacula begins execution, and in some cases the problem may be more
> >> >> fundamental because log files and cons files can be created at any
> >> >> time while Bacula is running.
> >> >
> >> >In this case why does bacula even support -u and -g parameters?
> >> >
> >> >If these parameters do not work as expected they should be either fixed
> >> >or removed.
> >>
> >> sorry wednesday i was in an hurry,
> >> the fix is dead simple, bacula daemons should just reexec themselves
> >> after changing uid/gid.
> >
> >That is an interesting suggestion, but I am not at all sure it is
> > necessary. Bacula has no problem changing the user and/or group -- it
> > does that internally without re-execing.
> >
> >As I understand the problem it is: if you run the daemons as root, certain
> >files are created with root permission.  If you later decide to run the
> >daemons with -u and/or -g, the daemons may not be able to access certain
> > old files that were previously created.
> >
> >In my opinion, that is a one-time sys admin problem due to the options the
> > sys admin changes (or changing options because rpm installs have changed
> > or are different than previously) and, in my opinion, this is best
> > handled by a sys admin and by documentation.  However, perhaps I don't
> > understand the problem.
>
> No,
> the problem this is trying to solve is a different one.
> I fully agree about the sys admin problem.
> A sysadmin must choose what user bacula daemons will run as, and ensure
> file permission are correct based on this decision.
> It cannot be changed lightly.
>
> but once the sysadmin configures permission correctly bacula can be run
> with -u/-g in order to reduce privileges.
>
> If bacula is packaged by a distribution or other packager this decision
> probably will be done at the packager creation level.
>
> The problem with running bacula as a different user under linux is the
> one pointed by Eric at the start of this thread.
>
> under linux doing, as root:
> setuid(lower_privilege_uid);
> ...
> ptrace(..., getpid(), ..., ...);
> will result in ptrace erroring with EPERM.
>
> this prevents btraceback from working, since the invoked gdb will fail
> to attach to bacula.
>
> if you look at /proc/<pid> of a program that reduces
> privileges you will see most files there are still owned by root.
>
> if the program did something like
> if (getuid() == 0) {
>         setuid(lower_privilege_uid);
>         execv(argv[0],argv);
> }
> ...
> ptrace(..., getpid(), ..., ...);
>
> ptrace will work.

Very interesting!  That is something I did not know.  I will look into this a 
bit more ...

Thanks,

Kern

> if you look at /proc/<pid> of this second example
> you will see all files there are now owned by lower_privilege_uid.
>
> Eric worked around this by using start-stop-daemon to change uid/gid,
> then execute bacula, but:
> - bacula has -u/-g options so they should work as advertised.
> - bacula fd can be run as a different user while keeping the READALL
>    capability, changing uid before running bacula renders this option
>    impossible.
>
> Regards,
> L.



------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to