Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.micro.att,net.unix
Subject: Re: ls permission "l"?
Message-ID: <7510@sun.uucp>
Date: Mon, 22-Sep-86 17:46:39 EDT
Article-I.D.: sun.7510
Posted: Mon Sep 22 17:46:39 1986
Date-Received: Tue, 23-Sep-86 06:00:38 EDT
References: <197@osi3b2.UUCP> <157@sheba.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 28
Xref: mnetor net.micro.att:1488 net.unix:5590

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