Re: Filesystem Capabilities in 2.6?

Linus Torvalds (torvalds@transmeta.com)
Mon, 4 Nov 2002 13:50:24 -0800 (PST)


On Mon, 4 Nov 2002, Ulrich Drepper wrote:
> int
> main()
> {
> system ("cp -f u1 uu");
> int fd = open ("./uu", 0);
> char buf[100];
> sprintf (buf, "/proc/self/fd/%d", fd);
> char buf2[100];
> int n = readlink (buf, buf2, sizeof (buf2));
> buf2[n] = '\0';
> system ("cp -f u2 uu");
> execl (buf, buf2, "hallo", 0);
> return 0;
> }
> $ gcc -c o u u.c
> $ ./u
>
>
> You should see 'u2' as the result. But this is exactly what the fexecve
> call is supposed to prevent. The file, once opened, should be reused.
> The expected result is 'u1'.

No, you're wrong.

Your "cp -f" will _overwrite_ the already existing "uu" file. So the "cp"
is actually overwriting the old binary, and it prints out "u2" as a
result: which is exactly the expected behaviour of "fexecve()". If you
change the file itself, there's no way to execve() the old contents,
because the old contents simply do not exist. That's true of fexecve()
too.

To show what you want to show, you need to use "cp -fb" or something else
that actually _switches_ the file around from under you. Or make the
system() call do a "rm uu; cp uX uu". And if you do that, then you will
see "u1". Try it and see.

In other words, "execve(/proc/self/fd/xxx)" does work and is exactly the
same as fexecve().

Linus

-
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/