ls permission "l"?
Guy Harris
guy at sun.uucp
Tue Sep 23 07:46:39 AEST 1986
> 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 at sun.com (or guy at sun.arpa)
More information about the Comp.unix
mailing list