Messages in this thread | | | Subject | Re: Capabilities done right [diff against 2.3.1] | Date | Mon, 17 May 1999 22:18:27 -0400 | From | Horst von Brand <> |
| |
Pavel Machek <pavel@atrey.karlin.mff.cuni.cz> dijo:
[...]
> 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/
| |