Bug 486975 - kernel: Unable to write to file as non-root user with setuid and setgid bit set
kernel: Unable to write to file as non-root user with setuid and setgid bit set
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Cong Wang
Red Hat Kernel QE team
: Regression
Depends On:
  Show dependency treegraph
Reported: 2009-02-23 09:49 EST by Eugene Teo (Security Response)
Modified: 2013-09-29 22:08 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-30 03:09:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2009-02-23 09:49:33 EST
From Sathisha Poojary:
I was working with RHEL 5 update 3 and noticed a minor inconvenience which was a side effect of the RHEL5.3 patch BZ#463687 [kernel: open() call allows setgid bit when user is not in new file's group].

Steps to reproduce the issue:

#mkdir /newdir
#touch /newdir/file1
#chmod 06777 /newdir/file1

#su newuser
$dd if=/dev/null of=/newdr/file1
dd: opening '/newdir/file1': Operation not permitted

However the dd works with 'conv=notrunc' option.

I noticed this because one of my test cases failed, but not sure whether there might be any real use cases around this. You might be the better person to judge the priority of this issue.
Comment 3 Eric Sandeen 2009-02-23 17:11:11 EST
It doesn't seem like a *security* issue to me; it's denying an action, not granting an action we expect to be denied.  Eugene, do you concur?

Anyway, specifically here in inode_change_ok():

        /* Make sure a caller can chmod. */
        if (ia_valid & ATTR_MODE) {
                if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER))
                        goto error;

we are trying to change the mode (due to the suid stripping) but we don't have perms to do that.

On the notrunc write path, we call file_remove_suid(), which sets the ATTR_FORCE flag and we are therefore able to remove the suid bits & continue.

I think perhaps do_truncate() should also be just calling file_remove_suid().

I'll check into this upstream (same behavior there, FWIW)

Comment 4 Eric Sandeen 2009-02-23 17:18:25 EST
Yep, with that change it works as (I think) it should:

[root@inode ~]# ls -l /newdir/
total 0
-rwsrwsrwx 1 root root 0 2009-02-23 15:57 file1
[root@inode ~]# su newuser

[newuser@inode root]$ dd if=/dev/zero of=/newdir/file1 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000641472 s, 798 kB/s
[newuser@inode root]$ ls -l /newdir/
total 4
-rwxrwxrwx 1 root root 512 2009-02-23 16:17 file1
Comment 5 Eugene Teo (Security Response) 2009-02-23 21:52:41 EST
(In reply to comment #3)
> It doesn't seem like a *security* issue to me; it's denying an action, not
> granting an action we expect to be denied.  Eugene, do you concur?

I concur. I'm opening this bug so that this can be dealt with as a normal bug.

Thanks Eric!
Comment 7 Eugene Teo (Security Response) 2009-06-25 06:47:03 EDT
Proposed patch:
Comment 8 Cong Wang 2009-07-06 01:16:45 EDT
V2: http://lkml.org/lkml/2009/7/6/10
Comment 9 Cong Wang 2009-08-21 06:08:36 EDT
FYI: The final version: http://lkml.org/lkml/2009/8/19/5. Already merged into James' tree.
Comment 14 Don Zickus 2009-10-21 15:11:20 EDT
in kernel-2.6.18-170.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 16 Petr Beňas 2010-03-01 10:08:19 EST
Bug state changed from ON_QA to VERIRIED.

$ cat do-my-test 
mkdir /newdir
touch /newdir/file1
chmod 06777 /newdir/file1
useradd newuser
su newuser -c 'dd if=/dev/null of=/newdir/file1'

[root@dell-pe2850-01 486975]# uname -r
[root@dell-pe2850-01 486975]# make run
chmod a+x ./runtest.sh ./do-my-test
Running ./do-my-test  As root: 
dd: opening `/newdir/file1': Operation not permitted
...finished running ./do-my-test, exit code=1
/kernel/errata/5.5/486975 result: FAIL
   Log: /tmp/tmp.fl3750

[root@dell-pe2850-01 486975]# uname -r
[root@dell-pe2850-01 486975]# make run
chmod a+x ./runtest.sh ./do-my-test
Running ./do-my-test  As root: 
0+0 records in
0+0 records out
0 bytes (0 B) copied, 1.9e-05 seconds, 0.0 kB/s
...finished running ./do-my-test, exit code=0
/kernel/errata/5.5/486975 result: PASS
   Log: /tmp/tmp.oe3263
   DMesg: /tmp/dmesg.log
Comment 18 errata-xmlrpc 2010-03-30 03:09:35 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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