Bug 486975

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