* suid bit behaviour modification in 2.6.0-test5
@ 2003-09-21 0:45 Jean-pierre Cartal
2003-09-22 3:25 ` Ian Hastie
0 siblings, 1 reply; 6+ messages in thread
From: Jean-pierre Cartal @ 2003-09-21 0:45 UTC (permalink / raw)
To: linux-kernel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: suid bit behaviour modification in 2.6.0-test5
2003-09-21 0:45 suid bit behaviour modification in 2.6.0-test5 Jean-pierre Cartal
@ 2003-09-22 3:25 ` Ian Hastie
2003-09-23 17:12 ` bill davidsen
0 siblings, 1 reply; 6+ messages in thread
From: Ian Hastie @ 2003-09-22 3:25 UTC (permalink / raw)
To: linux-kernel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: suid bit behaviour modification in 2.6.0-test5
2003-09-22 3:25 ` Ian Hastie
@ 2003-09-23 17:12 ` bill davidsen
2003-09-23 17:54 ` Andries Brouwer
0 siblings, 1 reply; 6+ messages in thread
From: bill davidsen @ 2003-09-23 17:12 UTC (permalink / raw)
To: linux-kernel
In article <200309220425.21862.lkml@ordinal.freeserve.co.uk>,
Ian Hastie <lkml@ordinal.freeserve.co.uk> 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 majordomo@vger.kernel.org
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
|
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: suid bit behaviour modification in 2.6.0-test5
2003-09-23 17:12 ` bill davidsen
@ 2003-09-23 17:54 ` Andries Brouwer
2003-09-26 22:41 ` Ian Hastie
0 siblings, 1 reply; 6+ messages in thread
From: Andries Brouwer @ 2003-09-23 17:54 UTC (permalink / raw)
To: bill davidsen; +Cc: linux-kernel
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: suid bit behaviour modification in 2.6.0-test5
2003-09-23 17:54 ` Andries Brouwer
@ 2003-09-26 22:41 ` Ian Hastie
2003-09-29 3:05 ` Ian Hastie
0 siblings, 1 reply; 6+ messages in thread
From: Ian Hastie @ 2003-09-26 22:41 UTC (permalink / raw)
To: Andries Brouwer; +Cc: linux-kernel, bill davidsen
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: suid bit behaviour modification in 2.6.0-test5
2003-09-26 22:41 ` Ian Hastie
@ 2003-09-29 3:05 ` Ian Hastie
0 siblings, 0 replies; 6+ messages in thread
From: Ian Hastie @ 2003-09-29 3:05 UTC (permalink / raw)
To: Andries Brouwer; +Cc: linux-kernel, bill davidsen
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-09-29 3:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-21 0:45 suid bit behaviour modification in 2.6.0-test5 Jean-pierre Cartal
2003-09-22 3:25 ` Ian Hastie
2003-09-23 17:12 ` bill davidsen
2003-09-23 17:54 ` Andries Brouwer
2003-09-26 22:41 ` Ian Hastie
2003-09-29 3:05 ` Ian Hastie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox