Print

Print


Hi Brian,

I do understand that. What we found in practice is that typical admins pick 
a username for the daemon which then becomes the defacto admin account as 
well. This is largely done out of convenience since the daemon account owns 
all of the files and you need to be able to manage the files at times as 
well. Trying to juggle two or more accounts to do this is just a royal pain 
when you know quite well that the daemon never modifies the config file. 
Sometimes, in these things, we work against our best interests (on either 
side), sigh.

Andy

-----Original Message----- 
From: Brian Bockelman
Sent: Monday, June 06, 2011 3:45 PM
To: Andrew Hanushevsky
Cc: Doug Benjamin ; Lukasz Janyst ; xrootd-dev
Subject: Re: Ownership of configuration files in RPM

Hi Andy,

I'm not saying these files should be owned by root, I'm saying that the 
daemon shouldn't be able to write to its own configuration files as a 
standard security precaution.  I.e., if the config files are owned by "abh" 
and the daemon runs as "xrootd", then I have no problem.

There are other ways to attack this on Linux, such as using SELinux or bind 
mounts such that the xrootd process cannot access /etc.

Brian

On Jun 6, 2011, at 5:39 PM, Andrew Hanushevsky wrote:

> Doesn't the OSG RPM do this already? I agree with Doug that this is 
> necessary at many sites. You can't always assume that everyone will have 
> root privileges or that the person that has root privileges will 
> administer everything. It's quite unrealistic as we found at SLAC and 
> IN2P3. So, I suppose either we get a +rpm or ATLAS recommends that the OSG 
> rpm be used.
>
> Andy
>
> -----Original Message----- From: Doug Benjamin
> Sent: Monday, June 06, 2011 1:17 PM
> To: Lukasz Janyst
> Cc: Brian Bockelman ; xrootd-dev
> Subject: Re: Ownership of configuration files in RPM
>
> Hi Lukasz,
>
>   There are several Tier 3 sites where the system administration (OS etc) 
> is separate from the
> experiment software administration. Thus one needs to be able change 
> configurations on the fly.
> this is not possible without root priv if root ownes the  configuration 
> files.  One possible solution
> would be to have a separate rpm that can be run to change the ownership to 
> the same account that runs
> the xrootd service.  This way the original rpms installs everything with 
> root ownership, but the separate
> rpm can make the change with a proper switch.
>
> Doug
>
>
> Lukasz Janyst wrote:
>> 2011/6/6 Brian Bockelman <[log in to unmask]>:
>>> Let's make this a switch someone can throw in the RPMs at build time 
>>> then: certainly it's not a recommended practice.
>>
>>   Yeah, I will do this if it's really necessary but I would like to
>> avoid having too many build switches because I would then have to
>> build and distribute the packages with all the possible switch
>> configurations. I would prefer to drop this altogether. Doug, do you
>> really have a use case that depends on this? It seems to be very
>> far-fetched.
>>
>>   Lukasz