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. However, there is atleast one other example where something like this exists and there is a counter for that. We can learn from the counter.
Consider the LD_PRELOAD env variable. The dynamic linker ignores this variable (well there are suitable exceptions clearly defined in the ld.so manpage) the moment it sees that the child is a root process. Thus, even though the parent had changed the effective behavior of dynamic linking , the child doesn't suffer from the same. In my prototype, currently, I am okay because the basis of the functionality is an interposing library which is ignored if somebody does and 'su'. 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. 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. For mutiple threads we will have to use mutual exclusion on the 'userspace vfs' to keep race conditions out... similar to many other things (like malloc et al). Ritesh On 4/19/05, Al Viro <[EMAIL PROTECTED]> wrote: > On Tue, Apr 19, 2005 at 11:02:53PM -0400, Ritesh Kumar wrote: > > I am new to the list so please bear with me :-) > > > > I have also be thinking about filesystem namespaces which are > > completely under the user's own control. > > How do you deal with su(1) finding /etc/shadow in your namespace > and seeing an entry for root there - with no password? > > > I was also thinking of them > > being inherited and changed along the process heirarchy. > > We have that already... > > > So a given > > process is allowed to change its namespace any way it likes and map it > > to its parent's namespace. > > See above. > > > More importantly, I was thinking in terms of having this entire > > capability in the userspace itself. Instead of giving all the details > > right here... let me redirect you to the page where I have set up the > > prototype. You should be able to download the sample code (very small) > > and browse through it to get an idea of what I had in mind. I also > > have an article which explains what I was thinking. In essense, I was > > thinking of splitting up the conceps of 1) accessing the filesystem on > > the HDD/device and 2) setting up a namespace for accessing the files > > into two separate concepts and bringing up 2) completely in the > > userspace. > > What do you think? I would like to have feedback on the idea. > > That your library will leave any suid program seeing hell knows > what. Which gets very unpleasant when you are using it to do something > with your files... > > That's besides the issues with races when two tasks that share > namespace attempt to change it. > > > http://www.cs.unc.edu/~ritesh/projects/perprocessfs.html > -- Rationality is the fundamental limitation to all human thought. - 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
