🚀 go-pugleaf

> 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)