Subject: Re: chmod(1) and '+X'
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/18/2004 19:14:43
[ On Sunday, January 18, 2004 at 18:48:13 (+0100), Jesper Louis Andersen wrote: ]
> Subject: Re: chmod(1) and '+X'
> Quoting Perry E. Metzger (email@example.com):
> > > IRIX' chmod and GNU chmod remove the 'x' bit.
> > If Solaris' does the same, I'd say we have consensus.
> Hmm, is all those anything but old SystemV descendants?
"old" is a relative term here :-)
If I'm not mistaken each of the SysVr4 derivatives still in relatively
wide distribution has always had a quite independent source tree (and
that no doubt goes double or triple for Sun) and traditionally both Sun
and SGI have been quite enamoured with their own local changes, so
there's still lots of room for disagreement between them. :-)
I'd guess Sun would be more likely to make a change to the way a tool
like "chmod" would work than SGI would, though I suppose that's not
really relevant. Sun also have had a tradition of providing separate
standards-compliant tools (xpg4), and SGI may have done the same (I have
much less experience with SGI releases).
> What about
> 4.4bsd and it's behaviour?
We can use the source for that comparison. :-)
From what I can see just from a very quick scan of the diffs of 4.4BSD
setmode.c vs NetBSD's setmode.c, NetBSD's chmod will have diverged in
how it interprets its parameters a bit from 4.4BSD's, though according
to the changelog it's mostly a result of bug fixes by cdg that are not
directly related to the 'X' permissions modifier.
> (no, I am not on sure ground here, I just want to weed out the
> possibility that there are 2 main ways of doing it)
I NetBSD's manual page (which remains unchanged in this part since
4.4BSD) has as good an explanation of 'X' as any. Alone this seems to
indicate the documented issue with '-X' is indeed in conflict with the
X The execute/search bits if the file is a directory or any
of the execute/search bits are set in the original (unmodi-
fied) mode. Operations with the perm symbol ``X'' are only
meaningful in conjunction with the op symbol ``+'', and are
ignored in all other cases.
As for standards-compatability, well as I think has already been quoted,
IEEE Std 1003.1-2001 has this to say:
The perm symbol X shall represent the execute/search portion of the
file mode bits if the file is a directory or if the current
(unmodified) file mode bits have at least one of the execute bits
(S_IXUSR, S_IXGRP, or S_IXOTH) set. It shall be ignored if the
file is not a directory and none of the execute bits are set in the
current file mode bits.
First off these two sentences seem to contradict themselves w.r.t. what
should happen when the file is not a directory, however I would put more
weight in the second sentence.
The RATIONALE section of IEEE Std 1003.1-2001 explains why the current
behaviour of NetBSD's "chmod" w.r.t. "-X" (and hopefully "=X") is
correct and that our manual page is simply out-of-date:
The X perm symbol was adopted from BSD-based systems because it
provides commonly desired functionality when doing recursive (-R
option) modifications. Similar functionality is not provided by
the find utility. Historical BSD versions of chmod, however, only
supported X with op+; it has been extended in this volume of IEEE
Std 1003.1-2001 because it is also useful with op=. (It has also
been added for op- even though it duplicates x, in this case,
because it is intuitive and easier to explain.)
As for acting on non-directories, well if it does then that may be a
separate bug (or deviation from POSIX) in the NetBSD implementation
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>