On Wed, Dec 05, 2012 at 01:08:14PM -0500, Mouse wrote: > > This system call embodies a fairly fundamental shift away from the > > Unix model that object permissions are checked when you get a handle > > to an object -- not when you use that handle. > > Actually, I think that's true only of file descriptors.
That may be, but it's still true of file descriptors. Traditionally they're capabilities, and I really don't like the idea of rearranging that arbitrarily and inconsistently. I think to do this correctly, exec and search on file handles needs to be handled the same as read and write: you must open with the corresponding O_ flag, and that then gives you a capability that remains valid until closed (or revoke(2)'d). Because passing capabilities around is potentially dangerous, if we're going to add new capabilities we need to either be certain that no restrictions are needed, or add a mechanism to restrict capability passing. Since we clearly aren't certain (if anything, we're certain that restrictions are needed), someone needs to come up with a mechanism. There is a good bit of prior art we can take from in existing or historical capability systems, so designing a suitable mechanism and interface will probably take a bit of reading but shouldn't be very hard. Just remember that the process root directory is also a form of capability, and it shouldn't be that hard to figure out how to make everything interact. This does mean we aren't going to be POSIX-compliant on O_EXEC and O_SEARCH (are there any other O_ flags involved?) but I think it's become clear that this is inevitable. When we're done we can decide if O_EXEC and O_SEARCH and the corresponding other bits should disappear or not when _POSIX_SOURCE and friends are defined to request strict POSIX. We also need to decide if the process root dir and process current dir are equivalent to file handles and are thus capabilities (meaning search permission does not need to be checked again at use time) or not. This could go either way and I don't currently have an opinion. We're also going to need a way to encode capabilities such that they can be passed down from syscall code into vfs and filesystem code. When the only path requiring alternate forms of security check was truncate, it was ok to deal with it on an ad hoc basis; but now there are a lot of places that need to check either permissions or a capability, and I really don't want to be doing it in anything other than a systematic manner, especially in namei. And, manu still hasn't reverted the broken O_SEARCH logic he committed along with the *at calls. I guess I'm going to need to do that. -- David A. Holland dholl...@netbsd.org
