 |
 |
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