LFS-5.1-pre1 info

Remco remco at d-compu.dyndns.org
Sat Jan 31 01:57:52 PST 2004


Alexander E. Patrakov wrote:

> Matthew Burgess wrote:
> 
>>lfs-bootscripts 0.12 - 0.13
>>lfs-utils 0.4.2 - 0.4.3 (untested, we trust Zack right :) )
>>  
>>
> Then I add a wish to the list, concerning bootscripts:

> 
> And a side note. The "loadproc" and "killproc" as defined by LSB (get
> the pid from a file in /var/run) are IMHO not well designed. They cannot
> be implemented correctly at all if a program cannot put its pid file in
> /var/run due to insufficient permissions. Currently this includes MySQL,
> Apache, SQUID (they run from another user and /var/run is writable only
> by root) and BIND (it is chrooted and cannot access /var/run). So why
> follow this bad standard and not wait until it is corrected?
> 


I'm currently using the following "solution" to the write protection problem
of /var/run. I give group 'daemon' write permissions on directory /var/run. 
I also set the sticky bit.

Next I make sure that every daemon that wants to store its pid in /var/run
is a member of the 'deamon' group. (group 'daemon' should NOT be the
primary group to avoid that files are going to be owned by group 'daemon')

As far as I can see, assuming that daemon processes will run as unprivileged
users, this way daemon processes can only modify files owned by themselves. 

So one process running as an unprivileged user cannot modify/delete another
process' pid file. Although it can read the pid files (the ones that are
world readable), it cannot use the pid file to kill the process found
inside.

This way /var/run could probably even live without world read rights, as
long as processes that need to store their pid as an unprivileged user are
part of the 'daemon' group. (didn't try this yet)




More information about the lfs-dev mailing list