james@osi3b2.UUCP (James R. Van Artsdalen) (09/20/86)
I have access to a 3b2-310 running System V 2.1 (virtual memory version). When 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)? -- James R. Van Artsdalen ...!ut-ngp!utastro!osi3b2!james Live Free or Die
guy@sun.uucp (Guy Harris) (09/21/86)
> 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)
whp@cbnap.UUCP (W. H. Pollock x4575 3S235) (09/22/86)
The "l" means the file has mandatory file locking turned on. This is
enabled by some strange combination of modes, something like 02767. See
the chmod man page for more details.
Wayne H. Pollock,
UUCP: ...{ihnp4,cbatt}!cbnap!whp
DELPHI: WHP
GEnie: W.POLLOCK
"The opinions expressed above are ficticious. Any resemblance
to the opinions of persons living or dead is purely coincidental."stone@sheba.UUCP (09/22/86)
In article <197@osi3b2.UUCP> james@osi3b2.UUCP (James R. Van Artsdalen) writes: >I have access to a 3b2-310 running System V 2.1 (virtual memory version). When >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 > >Anybody know what the "l" means (or >would mean on a more appropriate file)? This is an artifact of the new file/record locking scheme provided via fcntl(2) and lockf(3). The "l" means that locking done on the file or portions of it will be mandatory locking. There are two types of locking provided, mandatory and advisory. Mandatory locks are obeyed by all processes, while advisory locks are only visible to other processes also using advisory locks. By default all locks are advisory. To make mandatory locks the "Set Group ID" bit needs to be set first on the file. So now the SGID bit has two meanings. Chmod(1) has been changed to disallow chmod s+g on files that are not executable, and to disallow chmod +l (set mandatory locking) on files that are executable. But chmod(2) has not been changed to prevent this. So what you are seeing is ls(1) being confused by seeing the SGID bit set on a file that is not executable. David Stone Arete Systems !sun!arete!stone or {grape,dlb,cdp,hplabs!hpspdla}!sheba!stone
guy@sun.uucp (Guy Harris) (09/23/86)
> Chmod(1) has been changed to disallow chmod s+g on files that are not > executable, and to disallow chmod +l (set mandatory locking) on files > that are executable. But chmod(2) has not been changed to prevent this. And can't be so changed, either. There is not difference between setting the set-GID bit and specifiying mandatory locking, so disallowing setting the set-GID bit on a non-executable file would disallow specifying mandatory locking. It would also break "at"; see my previous posting for an explanation of *why* "at" jobs have the set-UID and set-GID bits set. Note, BTW, that a consequence of using the set-GID bit for this purpose is that giving a file away to somebody else clears the mandatory locking bit on the file, and since the file has been given away only the new owner or the super-user can turn mandatory locking back on.... > So what you are seeing is ls(1) being confused by seeing the SGID bit set > on a file that is not executable. No, "ls" isn't confused; it's saying that the file has mandatory locking enabled. The trouble is that the presence of the set-GID bit may cause locks on this file to be mandatory, but that's not what's interesting in this case. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)