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.
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.
--
Luca Berra -- bl...@comedia.it
------------------------------------------------------------------------------
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
