Bug 801522 - /usr/bin/install fails to explicitly set permissions when parent has sticky bit set
/usr/bin/install fails to explicitly set permissions when parent has sticky b...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
5.8
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ondrej Vasik
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-08 13:02 EST by Jason Bradley Nance
Modified: 2016-05-24 12:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-07 11:38:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Bradley Nance 2012-03-08 13:02:01 EST
Description of problem:
/usr/bin/install is failing to set the permissions specified by a "-m" when the parent directory has a group sticky bit set.

Version-Release number of selected component (if applicable):
coreutils-5.97-34.el5.x86_64

How reproducible:
100%

Steps to Reproduce:
install -m 2755 -d /tmp/foo
install -m 0750 -d /tmp/foo/bar
  
Actual results:
drwxr-sr-x 3 root root 4096 Mar  8 17:49 /tmp/foo
drwxr-s--- 2 root root 4096 Mar  8 17:49 /tmp/foo/bar

Expected results:
drwxr-sr-x 3 root root 4096 Mar  8 17:49 /tmp/foo
drwxr-x--- 2 root root 4096 Mar  8 17:49 /tmp/foo/bar

Additional info:
The strace shows install calling mkdir() with the mode argument.

...
umask(0)                                = 027
stat("/tmp/foo/bar", 0x7fffc90d8e10)    = -1 ENOENT (No such file or directory)
umask(0)                                = 0
open(".", O_RDONLY)                     = 3
chdir("/")                              = 0
mkdir("tmp", 0750)                      = -1 EEXIST (File exists)
chdir("tmp")                            = 0
mkdir("foo", 0750)                      = -1 EEXIST (File exists)
chdir("foo")                            = 0
umask(0)                                = 0
mkdir("bar", 0750)                      = 0
...

The documentation for install says the following regarding -m:

      -m, --mode=MODE
              set permission mode (as in chmod), instead of rwxr-xr-x

To me this says "set the permissions to this explicitly".

So I believe that install needs to do a chmod(), not just set the permissions in the call to mkdir().
Comment 1 Jason Bradley Nance 2012-03-08 13:20:10 EST
Apparently OpenBSD considered this mkdir() behavior a bug and has resolved it within the call to mkdir():

http://www.openbsd.org/cgi-bin/cvsweb/src/bin/mkdir/mkdir.c?rev=1.24;content-type=text%2Fx-cvsweb-markup

From mkdir.c:

	rv = mkdir(*argv, mode);
	/*
	 * The mkdir() and umask() calls both honor only the
	 * low nine bits, so if you try to set a mode including
	 * the sticky, setuid, setgid bits you lose them. Don't
	 * do this unless the user has specifically requested
	 * a mode as chmod will (obviously) ignore the umask.
	 */
	if (rv == 0 && mode > 0777)
		rv = chmod(*argv, mode);
Comment 2 Ondrej Vasik 2012-12-12 14:05:08 EST
I doubt this will get fixed in RHEL-5. There was a strong discussion about "enough explicit" mode and special bits handling. Openbsd implementation is very different from the GNU coreutils. Required changes (were done after discussion about similar problem in RHEL-6) were done upstream as http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=4730c3e3692b344effb72d46b3ff92db0bdb797a . More details and some discussion pointers are in https://bugzilla.redhat.com/show_bug.cgi?id=691466 (it is about chmod, but the install is using same gnulib functions, so technically the same issue).

With install -m 00750 -d /tmp/foo/bar you can get this behaviour on RHEL-6.3+ . Just 0750 will not work anywhere - because of the risk of confusion with octals. If you have strong need for the fix in RHEL-5, please contact Red Hat support and discuss the posibilities with them. This may increase the chances for RHEL-5.
Comment 3 Ondrej Vasik 2013-03-07 11:38:16 EST
RHEL-5.10 (the next RHEL-5 minor release) is going to be the first
production phase 2 [1] release of RHEL-5. Since phase 2 we'll be
addressing only security and critical issues. This bug report doesn't qualify for it.
This one issue is already fixed (ok, at least somewhat) in RHEL-6 therefore I am closing the bug as WONTFIX for RHEL-5.

[1] https://access.redhat.com/support/policy/updates/errata/

Note You need to log in before you can comment on or make changes to this bug.