[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: