Re: suid bit behaviour modification in 2.6.0-test5

[Ian Hastie <ianh@iahastie.clara.net>]

On Tuesday 23 Sep 2003 18:54, Andries Brouwer wrote:
> On Tue, Sep 23, 2003 at 05:12:59PM +0000, bill davidsen wrote:
> > Well, if ls gets that bit as still set, what would happen if someone
> > actually ran the program before the sync was done? COuld the file be
> > modified and then run? Is there a window? Still smells bugish.
>
> I don't know why you people continue the debate - is anything wrong
> with the fix I sent?

This is the fix that went into test5-bk11?  Now that i2c seems to be 
initilising properly again I've been able to test it in bk13.  I get exactly 
the same results as before the patch.  BTW, something I should have mentioned 
before is that this is on an XFS partition.

Just did a slightly different test and got this from it...

$ uname -a
Linux iahastie 2.6.0-test5-bk13-athlon #1 Fri Sep 26 19:26:30 BST 2003 i686 
GNU/Linux
$ touch suid_test
$ ls -l
total 0
-rw-r--r--    1 ianh     ianh            0 Sep 26 23:16 suid_test

# chown root suid_test
# chmod 4775 suid_test

$ ls -l
total 0
-rwsrwxr-x    1 root     ianh            0 Sep 26 23:16 suid_test
$ cp /usr/bin/id suid_test
$ ls -l
total 16
-rwsrwxr-x    1 root     ianh        13880 Sep 26 23:16 suid_test
$ ./suid_test
uid=1000(ianh) gid=1000(ianh) euid=0(root) groups=1000(ianh), ...

Note it *does* come up as euid root.

$ sync
$ ls -l
total 16
-rwxrwxr-x    1 root     ianh        13880 Sep 26 23:16 suid_test
$ ./suid_test
uid=1000(ianh) gid=1000(ianh) groups=1000(ianh), ...

But not after it has been synced.  Odd, but that's how it works.

As I said before it seems to me that this is coming from an old cached version 
of the directory entry.  As such that version will need to be cleared from 
the cache at the same time as updating the s(ug)id data on the file system 
itself.

-- 
Ian.