Re: /var/run permissions
On Tue, 13 Apr 1999, Jean Pierre LeJacq wrote:
>On Sun, 11 Apr 1999, Russell Coker wrote:
>
>> I have just been playing with the new authbind package (excellent work Ian).
>> It works fine however I do have problems with daemons wanting to write to
>> /var/run. If daemons were configured to truncate the pid file in /var/run on
>> exit then I could just put appropriate files in there with appropriate
>> ownership and things would be fine.
>> However most daemons want to create a file in /var/run at startup and delete it
>> at exit. This means that the daemon needs write access to /var/run. On my
>> test machine I have changed /var/run to be owned by group daemon, world and
>> group writable, and have the sticky bit set. This means that any daemon can
>> write a file there but daemons can't overwrite each other's files.
>>
>> What do you think of this idea? To take advantage of authbind we need to do
>> something about /var/run. My changes work, I believe that they (or some better
>> alternative that someone here comes up with) should be implemented.
>
>I have the same problem with the WN HTTP server.
>
>My reading of the FHS doesn't address the permissions issue so I
>believe your proposal would be FHS compatible.
>
>What would make your proposal different than the /tmp directory?
>Could we have the same well known security issues with /var/run?
I have my /var/run directory mode 1775. So group daemon can write to it but
average users can't. This avoids the same security issues as /tmp. If a user
gets group daemon then you probably have a bigger problem than sym-links in
/var/run.
Another potential solution to this problem is for authbind to include
"authopen" functionality too. Then you could configure that a program which
can access a particular port can also write a particular file in /var/run.
Russell Coker
Reply to: