Re: chmod octal form of sgid/suid removal fails

2007-05-15 Thread Paul Eggert 
Jan Engelhardt <[EMAIL PROTECTED]> writes:

> Since GNU is quite fond of `info`, do the info pages need fixing too?

No, thanks, they were updated long ago.  But I had forgotten to fix
the man pages at one point when I changed the info pages and code.


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-15 Thread Paul Eggert 
John Cowan <[EMAIL PROTECTED]> writes:

> However, if the directory has mode 6755 and you
> do "chmod 2755 dir", the mode remains 6755.

I hadn't thought of that example.  It's a good illustration of an
unfortunate corner in the current rules.  But I can't think of a
simple change to the rules that wouldn't introduce some of the other
corners we've been talking about.

One way to think about it is that the current rules are biased in
favor of setting the setuid and setgid bits on directories, since you
have to clear them with symbolic modes and cannot clear them with
numeric.  This can be thought of as a design policy: coreutils prefers
sharing (sort of a corollary of the overall GNU philosophy).  But it's
a weak reed I admit.


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-15 Thread Jan Engelhardt 

On May 15 2007 07:19, Jim Meyering wrote:
>Paul Eggert <[EMAIL PROTECTED]> wrote:
>> Thanks for mentioning that.  Here is a patch to the man page.
>>
>> 2007-05-14  Paul Eggert  <[EMAIL PROTECTED]>
>>
>>  * man/chmod.x: Document chmod's behavior with setuid and setgid bits.
>>  Remove misleading implication about leading zero.  Problem
>>  reported by Jan Engelhardt in
>>  .
>
>Thanks, Paul!
>I've applied that.

Since GNU is quite fond of `info`, do the info pages need fixing too?


Jan
-- 


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-14 Thread Jim Meyering 
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thanks for mentioning that.  Here is a patch to the man page.
>
> 2007-05-14  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * man/chmod.x: Document chmod's behavior with setuid and setgid bits.
>   Remove misleading implication about leading zero.  Problem
>   reported by Jan Engelhardt in
>   .

Thanks, Paul!
I've applied that.


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-14 Thread John Cowan 
(Apologies to those, if any, who got an earlier version of this message.)

Paul Eggert scripsit:

> The counterargument is that it's strange if a leading
> zero changes the semantics of a number, as this is not what many
> people expect.

Fair enough.  However, if the directory has mode 6755 and you
do "chmod 2755 dir", the mode remains 6755.  This violates the
Law of Least Astonishment, I think.

I had earlier thought that it doesn't matter, because setuid
doesn't mean anything on directories in most *ix variants, but
on FreeBSD it causes files created in the directory to be
owned by the directory owner, analogously to setgid.  See
http://www.greenend.org.uk/rjk/2004/perms.html for details.

> Please see the thread rooted here:

Thanks for the pointer.

> If you read that root, by the way, you'll see that existing practice
> is wildly different in this area.  For example, on Solaris,
> "chmod 2755 DIR" silently ignores the "2".

Quite so.  File modes are a mess, anyway.  I suppose that on the whole
stability trumps "correctness".

-- 
As you read this, I don't want you to feel  John Cowan
sorry for me, because, I believe everyone   [EMAIL PROTECTED]
will die someday.   http://www.ccil.org/~cowan
--From a Nigerian-type scam spam


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-14 Thread Paul Eggert 
Jan Engelhardt <[EMAIL PROTECTED]> writes:

> Then the manpgea is broken instead:;

Thanks for mentioning that.  Here is a patch to the man page.

2007-05-14  Paul Eggert  <[EMAIL PROTECTED]>

* man/chmod.x: Document chmod's behavior with setuid and setgid bits.
Remove misleading implication about leading zero.  Problem
reported by Jan Engelhardt in
.

diff --git a/man/chmod.x b/man/chmod.x
index 9a73cd5..a2b0bb2 100644
--- a/man/chmod.x
+++ b/man/chmod.x
@@ -1,4 +1,4 @@
-'\" Copyright (C) 1998, 1999, 2001, 2006 Free Software Foundation, Inc.
+'\" Copyright (C) 1998, 1999, 2001, 2006, 2007 Free Software Foundation, Inc.
 '\"
 '\" This is free software.  You may redistribute copies of it under the terms
 '\" of the GNU General Public License .
@@ -51,8 +51,7 @@ categories (\fBo\fP).
 .PP
 A numeric mode is from one to four octal digits (0\-7), derived by
 adding up the bits with values 4, 2, and 1.  Omitted digits are
-assumed to be leading zeros, except that if the first digit is
-omitted, a directory's set user and group ID bits are not affected.
+assumed to be leading zeros.
 The first digit selects the set user ID (4) and set group ID (2) and
 restricted deletion or sticky (1) attributes.  The second digit
 selects permissions for the user who owns the file: read (4), write (2),
@@ -72,6 +71,30 @@ In contrast,
 .B chmod
 ignores symbolic links encountered during recursive directory
 traversals.
+.SH "SETUID AND SETGID BITS"
+.B chmod
+clears the set-group-ID bit of a
+regular file if the file's group ID does not match the user's
+effective group ID or one of the user's supplementary group IDs,
+unless the user has appropriate privileges.  Additional restrictions
+may cause the set-user-ID and set-group-ID bits of
+.I MODE
+or
+.I RFILE
+to be ignored.  This behavior depends on the policy and
+functionality of the underlying
+.B chmod
+system call.  When in
+doubt, check the underlying system behavior.
+.PP
+.B chmod
+preserves a directory's set-user-ID and set-group-ID bits unless you
+explicitly specify otherwise.  You can set or clear the bits with
+symbolic modes like
+.B u+s
+and
+.BR g\-s ,
+and you can set (but not clear) the bits with a numeric mode.
 .SH "RESTRICTED DELETION FLAG OR STICKY BIT"
 The restricted deletion flag or sticky bit is a single bit, whose
 interpretation depends on the file type.  For directories, it prevents
M ChangeLog
M man/chmod.x
Committed as 47f84cfc97405d1c904016a4e5e6e9e009f33b67


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-14 Thread Paul Eggert 
John Cowan <[EMAIL PROTECTED]> writes:

> Well and good, but it seems to me that writing an explicit 0 actually
> does make an explicit request.

This topic came up when I first added that feature, and originally I
agreed with you, but others did not and their arguments were
persuasive.  The counterargument is that it's strange if a leading
zero changes the semantics of a number, as this is not what many
people expect.  Please see the thread rooted here:

http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html

If you read that root, by the way, you'll see that existing practice
is wildly different in this area.  For example, on Solaris,
"chmod 2755 DIR" silently ignores the "2".


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-12 Thread Jan Engelhardt 

On May 12 2007 12:07, Eric Blake wrote:
>
>According to Jan Engelhardt on 5/12/2007 8:50 AM:
>> Cc'ed bug-coreutils.
>> The following bug affects at least:
>>  coreutils 6.4 (used in opensuse 10.2 - open a bug report here)
>>  coreutils 6.9
>> 
>> $ mkdir /dev/shm/me
>> $ strace -e chmod chmod 0755 me
>> chmod("me", 02755)  = 0
>
>Not a bug, and this is becoming a FAQ.  POSIX explicitly leaves the
>special mode bits undefined when using octal permissions.  And the NEWS
>for coreutils 6.0 is quite explicit:
[...]

Then the manpgea is broken instead:;

A numeric mode is from one to  four  octal  digits  (0-7),  derived  by
adding up the bits with values 4, 2, and 1.  Omitted digits are assumed
to be leading zeros, except that if  the  first  digit  is  omitted,  a
directory's  set  user  and  group ID bits are not affected.

Which seems to imply that if I specify a leading "0", they are affected.


Jan
-- 


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-12 Thread John Cowan 
Eric Blake scripsit:

>   chmod, install, and mkdir now preserve a directory's set-user-ID and
>   set-group-ID bits unless you explicitly request otherwise.  

Well and good, but it seems to me that writing an explicit 0 actually
does make an explicit request.

>   To clear the bits, mention them explicitly in a symbolic mode, e.g.,
>   `mkdir -m u=rwx,go=rx,-s DIR'.  To set them, mention them explicitly
>   in either a symbolic or a numeric mode, e.g., `mkdir -m 2755 DIR',
>   `mkdir -m u=rwx,go=rx,g+s' DIR.

No explanation is given for this asymmetric behavior.  It seems to me
that a fourth digit, if given, should be believed rather than treated
as an OR mask.

-- 
John Cowan  <[EMAIL PROTECTED]>
http://www.ccil.org/~cowan
.e'osai ko sarji la lojban.
Please support Lojban!  http://www.lojban.org


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: chmod octal form of sgid/suid removal fails

2007-05-12 Thread Eric Blake 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jan Engelhardt on 5/12/2007 8:50 AM:
> Cc'ed bug-coreutils.
> The following bug affects at least:
>  coreutils 6.4 (used in opensuse 10.2 - open a bug report here)
>  coreutils 6.9

> 
> $ mkdir /dev/shm/me
> $ strace -e chmod chmod 0755 me
> chmod("me", 02755)  = 0

Not a bug, and this is becoming a FAQ.  POSIX explicitly leaves the
special mode bits undefined when using octal permissions.  And the NEWS
for coreutils 6.0 is quite explicit:

  chmod, install, and mkdir now preserve a directory's set-user-ID and
  set-group-ID bits unless you explicitly request otherwise.  E.g.,
  `chmod 755 DIR' and `chmod u=rwx,go=rx DIR' now preserve DIR's
  set-user-ID and set-group-ID bits instead of clearing them, and
  similarly for `mkdir -m 755 DIR' and `mkdir -m u=rwx,go=rx DIR'.  To
  clear the bits, mention them explicitly in a symbolic mode, e.g.,
  `mkdir -m u=rwx,go=rx,-s DIR'.  To set them, mention them explicitly
  in either a symbolic or a numeric mode, e.g., `mkdir -m 2755 DIR',
  `mkdir -m u=rwx,go=rx,g+s' DIR.  This change is for convenience on
  systems where these bits inherit from parents.  Unfortunately other
  operating systems are not consistent here, and portable scripts
  cannot assume the bits are set, cleared, or preserved, even when the
  bits are explicitly mentioned.  For example, OpenBSD 3.9 `mkdir -m
  777 D' preserves D's setgid bit but `chmod 777 D' clears it.
  Conversely, Solaris 10 `mkdir -m 777 D', `mkdir -m g-s D', and
  `chmod 0777 D' all preserve D's setgid bit, and you must use
  something like `chmod g-s D' to clear it.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGReWU84KuGfSFAYARAhgoAKDL8wVkTUL6Zi7ELaYjmEUDacHzugCgyEvA
BKStpzgOAzhv9o9bZmCHJeU=
=oEzs
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils