Xref: utzoo comp.unix.questions:10304 comp.unix.wizards:12714
Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: what is the 'l' permission?
Keywords: atjobs
Message-ID: <483@auspex.UUCP>
Date: 21 Nov 88 21:34:31 GMT
References: <71@attibr.UUCP> <4594@ptsfa.PacBell.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 27


 >>When at at job is created on SVR3.x, here is the resulting files that
 >>are created:
 >>
 >>-r-Sr-lr--   1 root     other        571 Nov 17 18:00 595897200.a
 >>-r-Sr-lr--   1 root     other        865 Nov 18 09:45 595918800.a
 >>
 >>What does the 'l' mean in the group execute permission field?

 >According to the AT&T 3B4000 & 3B15 Computer UNIX System V User's and
 >System Administrator's Reference Manual Section 1 (305-205),
 >the l in the group execution slot means that mandatory locking will
 >occur during access.

Yes, but what it *really* means in some sense is "the set-GID bit is set
but the group execute bit isn't set."  There's no "mandatory locking"
permission bit; they ripped off the set-GID bit, saying it means
"mandatory locking" when the group execute bit isn't set.

The "S" means "set-UID bit is set, user execute bit isn't set";
"r-Sr-lr--" means "the only permission bits that are set are all three
read bits and the set-UID and set-GID bits".  "at" turns them on so that
it can detect some clever dick who creates an "at" job and gives it away
to user "root", attempting to trick "at" into running it as "root"; the
kernel turns the set-UID bit off when the ownership is changed (by
anybody but "root"), and "at" says "Fraud!" when it detects that the
magic Seal of Approval bits aren't set.