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.
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) Thanks, -Eric
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
(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!
Proposed patch: http://patchwork.kernel.org/patch/32338/
V2: http://lkml.org/lkml/2009/7/6/10
FYI: The final version: http://lkml.org/lkml/2009/8/19/5. Already merged into James' tree.
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.
Bug state changed from ON_QA to VERIRIED. $ cat do-my-test #!/bin/sh 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 2.6.18-169.el5 [root@dell-pe2850-01 486975]# make run chmod a+x ./runtest.sh ./do-my-test ./runtest.sh /mnt/tests/kernel/errata/5.5/486975/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 2.6.18-170.el5 [root@dell-pe2850-01 486975]# make run chmod a+x ./runtest.sh ./do-my-test ./runtest.sh /mnt/tests/kernel/errata/5.5/486975/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
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. http://rhn.redhat.com/errata/RHSA-2010-0178.html