OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: /var/lock permissions
From: Jim Dennis (jimdlinuxcare.com)
Date: Wed Jul 26 2000 - 12:32:10 CDT

Apparently Olaf Kirch <okircaldera.de> wrote:

> On Mon, Jul 24, 2000 at 06:54:23AM +0400, Solar Designer wrote:
>> Fix? I personally am going to add /var/lock/uucp and restrict
>> permissions on /var/lock itself (to 755) for the mtree specification
>> that I'm preparing (that's why I've spotted this). A workaround can
>> be to set the sticky bit on /var/lock, like it's done in Slackware.
 
> That's not optimal. User A's minicom/kermit/etc won't be able to remove
> a stale lockfile created by User B's minicom/kermit/uucico...
 
 So, do we need another SGID helper "lockfile" helper?

 Certainly the process of checking for and obtaining a lockfile
 (including checking for process status and stale lock removal)
 should be abstracted and consolidated into a single program.
 Getting the atomicity right and agreement on the lockfile format
 and naming is clearly difficult (it's been screwed up many times
 by many good programmers). It also makes sense that this should
 be subject to some system administration policies (for example
 one should be able to establish a policy that a lock on /dev/modem
 should by represented as /var/lock/ttyS0.LCK --- given that
 or that any chain of symlinks must be followed to the device
 node (or regular files, or UNIX domain socket?) and the lockfile
 named accordingly).

 If we had a good lockfile program (maybe starting with
 Stephen R. van den Berg's lockfile from procmail) we might
 have to make several copies of it for different application
 groups and make each of them SGID "modem", SGID "mail", etc

 What lockfile using application groups exist besides mail, and
 modem?

 Of course then we have to ask, how do we control access to
 the various copies of lockfile? I guess it could be done
 with directory permissions: /usr/bin/modem/lockfile,
 /usr/bin/mail/lockfile, etc. Each of those would be owned
 by a unique group and would not be world executable. Thus
 each of the copies of lockfile could be SGID something,
 each of the applications within each group would be SGID
 somethingelse, and only "somethingelse" members would be
 able to traverse the /usr/bin/${somethingelse}/ directory
 directory in order to execute the (world-executable, SGID)
 lockfile program.

 That seems ugly. Not quite as ugly as ACLs, but ... sort
 of "elegantly ugly."

  

--
Jim Dennis         Technical Research Analyst            Linuxcare, Inc.
             jimdlinuxcare.com, http://www.linuxcare.com/
             415 505-9306                415 701-7457 fax
                 Linuxcare: Support for the Revolution