[...]
> Is that missfeature of sh? I thought that it was race between sh being
> loaded and potential change of file. Malicious user could delete suid
> program and replace it with his own code with other name -- that is
> not easily worked around. So capabilities support will have to go into
> sperl, anyway.
Nope. And you could do the following (pseudocode!):
script = open("scriptfile", O_RDONLY);
check_and_set_caps(sprintf("/proc/self/%d", script));
execl("interpreter", sprintf("/proc/self/%d", script), any, others)
No race.
> Anyway, suid is currently not honoured by scripts. It will take
> _years_ before we'll get all tools like tar, cp, nfs, etc. work right
> with capbilities-in-namespace.
Better start today then. BTW, I'd say months is closer to the truth.
> By putting capabilities in name space
> you have to teach admins about new dangers: there are priviledged
> executables which have raised priviledges. These are all changes that
> are probably good thing - in distant future. But I think that we want
> something before that distant feature - and for common case (elf
> executables) solution is not that hard.
And putting them into the file doesn't have this very same problem?
> It may show that elf capabilities will be nice even when we have
> filesystem support: they have nice property of being able to travel
> across other unixes unharmed.
That is a misfeature, as it allows smuggling capabilities.
> Did I convince you now?
Nope.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/