Bug#576344: coreutils: [chmod] doesn't remove SUID and SGID bits from directories when using octal numbers

2010-04-03 Thread Joao Eriberto Mota Filho
Package: coreutils
Version: 7.4-2
Severity: normal

Hi!

When I make chmod (2xxx|4xxx|6xxx) over a directory, I can set SUID and SGID
bits. However, if I use 0xxx, the SUID and SGID bits aren't removed. But it can
be removed if using u-s and/or g-s. So I think it is a chmod bug and not a 
kernel bug.

I am using Squeeze but I tested it in Lenny too.

Thanks in advance.

Regards,

Eriberto - Brazil


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-3-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages coreutils depends on:
ii  libacl1   2.2.49-2   Access control list shared library
ii  libattr1  1:2.4.44-1 Extended attribute shared library
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib
ii  libselinux1   2.0.89-4   SELinux runtime shared libraries

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#576344: coreutils: [chmod] doesn't remove SUID and SGID bits from directories when using octal numbers

2010-04-03 Thread Bob Proulx
Joao Eriberto Mota Filho wrote:
 When I make chmod (2xxx|4xxx|6xxx) over a directory, I can set SUID
 and SGID bits. However, if I use 0xxx, the SUID and SGID bits aren't
 removed. But it can be removed if using u-s and/or g-s. So I think
 it is a chmod bug and not a kernel bug.

This is intentional behavior.  This behavior was changed in 2006.  The
goal was to make working with setgid directories easier.  In that
effort I think it is a good thing.  But personally I would rather have
seen this keep the numeric modes literal and only affect the symbolic
modes.  But it didn't work out that way.

As one of the dissenting votes I will direct you to the archive around
the time that this was implemented for the entire discussion.

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

In the NEWS file you will find this entry:

* Major changes in release 6.0 (2006-08-15) [unstable]

** Changes in behavior

  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.

Bob



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#576344: coreutils: [chmod] doesn't remove SUID and SGID bits from directories when using octal numbers

2010-04-03 Thread Bob Proulx
Oh, for the archive I should also point out that this is also
documented in the info pages.  I will include a direct link to the
documentation node.

Bob

  $ info coreutils 'Directory Setuid and Setgid'

26.4 Directories and the Set-User-ID and Set-Group-ID Bits
==

On most systems, if a directory's set-group-ID bit is set, newly
created subfiles inherit the same group as the directory, and newly
created subdirectories inherit the set-group-ID bit of the parent
directory.  On a few systems, a directory's set-user-ID bit has a
similar effect on the ownership of new subfiles and the set-user-ID
bits of new subdirectories.  These mechanisms let users share files
more easily, by lessening the need to use `chmod' or `chown' to share
new files.

   These convenience mechanisms rely on the set-user-ID and set-group-ID
bits of directories.  If commands like `chmod' and `mkdir' routinely
cleared these bits on directories, the mechanisms would be less
convenient and it would be harder to share files.  Therefore, a command
like `chmod' does not affect the set-user-ID or set-group-ID bits of a
directory unless the user specifically mentions them in a symbolic
mode, or sets them in a numeric mode.  For example, on systems that
support set-group-ID inheritance:

 # These commands leave the set-user-ID and
 # set-group-ID bits of the subdirectories alone,
 # so that they retain their default values.
 mkdir A B C
 chmod 755 A
 chmod 0755 B
 chmod u=rwx,go=rx C
 mkdir -m 755 D
 mkdir -m 0755 E
 mkdir -m u=rwx,go=rx F

   If you want to try to set these bits, you must mention them
explicitly in the symbolic or numeric modes, e.g.:

 # These commands try to set the set-user-ID
 # and set-group-ID bits of the subdirectories.
 mkdir G H
 chmod 6755 G
 chmod u=rwx,go=rx,a+s H
 mkdir -m 6755 I
 mkdir -m u=rwx,go=rx,a+s J

   If you want to try to clear these bits, you must mention them
explicitly in a symbolic mode, e.g.:

 # This command tries to clear the set-user-ID
 # and set-group-ID bits of the directory D.
 chmod a-s D

   This behavior is a GNU extension.  Portable scripts should not rely
on requests to set or clear these bits on directories, as POSIX allows
implementations to ignore these requests.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org