Hello,
I'm running a standard RH 9 installation upgraded to kernel 2.6.0-test5
with rpms from http://people.redhat.com/arjanv/2.5/RPMS.kernel/.
I noticed that contrary to what was happening with 2.4.x kernel, suid
root files don't loose their suid bit when they get overwritten by a
normal user (see example below)
Is this the intended behaviour or a bug ?
Example :
[cartaljp@localhost test]$ uname -r
2.6.0-0.test5.1.38
[cartaljp@localhost test]$ id
uid=500(cartaljp) gid=500(cartaljp)
[cartaljp@localhost test]$ touch suid_test
[cartaljp@localhost test]$ ls -l
total 0
-rw-rw-r-- 1 cartaljp cartaljp 0 Sep 19 07:55 suid_test
[cartaljp@localhost test]$ su -
Password:
[root@localhost test]# chown root ~cartaljp/test/suid_test
[root@localhost test]# chmod 4775 ~cartaljp/test/suid_test
[root@localhost test]# exit
[cartaljp@localhost test]$ ls -l
total 0
-rwsrwxr-x 1 root cartaljp 0 Sep 19 07:55 suid_test
[cartaljp@localhost test]$ cp /bin/ls suid_test
[cartaljp@localhost test]$ ls -l
total 72
-rwsrwxr-x 1 root cartaljp 67668 Sep 19 07:56 suid_test <-
Suid bit is still set whereas with 2.4.x kernel it was reset.
On Sunday 21 Sep 2003 01:45, Jean-pierre Cartal wrote:
> Hello,
>
> I'm running a standard RH 9 installation upgraded to kernel 2.6.0-test5
> with rpms from http://people.redhat.com/arjanv/2.5/RPMS.kernel/.
>
> I noticed that contrary to what was happening with 2.4.x kernel, suid
> root files don't loose their suid bit when they get overwritten by a
> normal user (see example below)
>
> Is this the intended behaviour or a bug ?
I got the same results. However it seems the bug is something to do with a
directory listing cache somewhere. If you sync after copying over the file
the suid bit is shown as having been cleared.
$ touch suid_test
# chown root suid_test
# chmod 4775 suid_test
$ ls -l
total 0
-rwsrwxr-x 1 root ianh 0 Sep 22 04:21 suid_test
$ cp /bin/ls suid_test
$ ls -l
total 68
-rwsrwxr-x 1 root ianh 69228 Sep 22 04:22 suid_test
$ sync
$ ls -l
total 68
-rwxrwxr-x 1 root ianh 69228 Sep 22 04:22 suid_test
--
Ian.
In article <[email protected]>,
Ian Hastie <[email protected]> wrote:
| On Sunday 21 Sep 2003 01:45, Jean-pierre Cartal wrote:
| > Hello,
| >
| > I'm running a standard RH 9 installation upgraded to kernel 2.6.0-test5
| > with rpms from http://people.redhat.com/arjanv/2.5/RPMS.kernel/.
| >
| > I noticed that contrary to what was happening with 2.4.x kernel, suid
| > root files don't loose their suid bit when they get overwritten by a
| > normal user (see example below)
| >
| > Is this the intended behaviour or a bug ?
|
| I got the same results. However it seems the bug is something to do with a
| directory listing cache somewhere. If you sync after copying over the file
| the suid bit is shown as having been cleared.
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.
|
| $ touch suid_test
|
| # chown root suid_test
| # chmod 4775 suid_test
|
| $ ls -l
| total 0
| -rwsrwxr-x 1 root ianh 0 Sep 22 04:21 suid_test
| $ cp /bin/ls suid_test
| $ ls -l
| total 68
| -rwsrwxr-x 1 root ianh 69228 Sep 22 04:22 suid_test
| $ sync
| $ ls -l
| total 68
| -rwxrwxr-x 1 root ianh 69228 Sep 22 04:22 suid_test
|
| --
| Ian.
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to [email protected]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
|
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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?
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.
On Friday 26 Sep 2003 23:41, Ian Hastie wrote:
> 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.
Just tried it again with 2.6.0-test6. Same initial results, but the suid bit
didn't clear directly after a sync, so that's probably just a coincidence.
Can't say for sure that there isn't some other change though. The only
certain thing here is that your suid bit fix doesn't work, at least not with
XFS.
--
Ian.