On Tue, Apr 19, 2005 at 11:38:21PM -0400, Ritesh Kumar wrote: > You are right. A more priviledged process running as a child of > another process should not be allowed to look at the same namespace as > its parent.
No go. That immediately breaks any suid program that takes a pathname as an argument and is supposed to do something to the file in question. Or uses dotfiles for per-user config. gpg(1) fits both, for example, and that's not something rarely used. Moreover, used in fsckload of scripts that are entirely out of your control, so something like "OK, use it on stdin, then" is not an answer (and it still doesn't address the second issue - gpg *does* need access to keyring, after all). > Also, the access control for the filesystem is still in the kernel. > What we change in the userspace is just the namespace and nothing > else. If you are fundamentally denied access to a file (from the > kernel) then you cannot access it no matter how you access it using > userspace libraries. The issue is not with being able to see something you shouldn't see. It's being able to trick more priveleged process into accepting your data as something it trusts. OR not being able to use suid programs on your own files at all. Neither is acceptable. BTW, your references to Plan 9 completely miss one very important thing - they manage to live without any suid stuff at all. Which is certainly very nice, but not useful in our case, unless you volunteer to rewrite suid applications to the form that would not need suid. > Plus, it is not very clear to me what to you mean by 'tasks'. If that > is processes, then the child will inherit a separate copy of the > namespace from the parent (Copy-on-write of the data structs of the > user library probably... I'll have to think over this). So no race > conditions here. ... and no working mount(8) either. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
