Why doesn't setfsuid return -EPERM when it can't perform the operation?
file: kernel/sys.c, 'sys_setfsuid' around line 779 depending on your
source version.
There is a check if capable(CAP_SETUID), that if it fails, doesn't
return an error. This seems inconsistent. I
Ok.. I'm going bananas. It could be a 4am braindeath or a rh7.0 bungholio
but this is annoying:
main(int argc, char **argv)
{
int fd;
setfsuid(atoi(argv[1]));
fd = open("/etc/passwd", O_RDONLY);
printf("got fd %d\n", fd);
}
[root@wizb
> Ok.. I'm going bananas. It could be a 4am braindeath or a rh7.0 bungholio
> but this is annoying:
There are lots of corner cases in the kernel that are probably a bit off
> main(int argc, char **argv)
> {
> int fd;
> setfsuid(atoi(argv[1]));
>
In article <[EMAIL PROTECTED]>,
Bjorn Wesen <[EMAIL PROTECTED]> wrote:
>
>in fact, 0 and 500 are the ONLY ones who let a filesystem op through after
>the setfsuid call. all other cause an EACCESS error on the open (or any
>other fs op). and yes, the actual filepermissions
On Mon, 8 Jan 2001, Linus Torvalds wrote:
> Please show them, anyway. What does "ls -ld / /etc /etc/passwd" say?
Heh... /etc and /etc/passwd were allright... but / was fscked (or not,
maybe :)
drwx- 500 0 both locked from other users and 500 as owner..
> 99% says that one of the t
[EMAIL PROTECTED] (Linus Torvalds) wrote on 08.01.01 in
<93d7fr$429$[EMAIL PROTECTED]>:
> And hey, if you think the above is confusing, try making your /dev/null
> a regular (writable) file by mistake. Now THAT will be confusing as
> hell: things will actually work surprisingly well, but some
6 matches
Mail list logo