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