🚀 go-pugleaf

> I did an "ls -l /usr/spool/cron/atjobs" I got this:
> 
> total 2
> -r-Sr-lr--   1 james    osi          740 Sep 18 06:14 527490000.a
> 
> I know what the "S" means, but I've never seen the "l" before.  My 2.0.4
> system stores an "S" in that spot for at jobs.  Anybody know what the "l"
> means (or would mean on a more appropriate file)?

"l"ock, presumably, as in "mandatory locking".  It means the set-GID bit is
set, but the group execute bit isn't.  The "/usr/group" standard for file
locking specified that if the set-GID bit is set on a file, all "lockf"
calls will be mandatory; i.e., they will lock out "read"s and "write"s as
well as other "lockf" calls.  Having all locks be mandatory creates obvious
security problems, especially if you don't need write access in order to
lock a file.

I guess UNIX needs mandatory locking - as opposed to OSes like OS/360 and
successors and VMS, which provide advisory locks that only act on arbitrary
resource names, not on files - because those other two operating systems are
not often used for commercial applications requiring locking, while UNIX
systems run them more frequently.

As for why those files have the set-UID and set-GID bits set, but no execute
bits: 1) "at" jobs are run with the UID and GID that own the job file and 2)
S5 lets you give any file you own away to somebody else.  Thus you could,
out of the kindness of your heart, give a job that does "rm -rf /" away to
"root"....  However, the set-UID and set-GID bits are cleared if you give
away a file (for obvious reasons), so "at" creates jobs with those bits on
and "cron" refuses to run them if the bits are off.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)