Alexander Viro writes:
> On Sat, 10 Jun 2000, Richard Gooch wrote:
> > Will it really make much difference? What would be harder to do
> > without mount IDs? And how much harder?
>
> Beware of functions with many arguments... Besides, what about "kill
> the component of union-mount on /barf NFS-mounted from
> venus:/foo/bar"? What exactly are you going to pass here? Such
> stuff is better left to userland.
Let's see. Pass the same stuff you see in /proc/namespace? Instead of
cut-and-paste of the mount ID, cut-and-paste the other entries on that
line. You're making the decision based on what's in /proc/namespace
anyway. Why add another level of indirection?
> > > And then... consider the situation when root logs in and decides to
> > > mess with luser's namespace.
> >
> > What about it?
>
> bastard@venus% su -
> Password:<clickety>
> root@venus% w luser
> ....
> luser pts/0 ...
> root@venus% ps t pts/0
> ....
> ....
> 728 pts/0 ...
> root@venus% cat /proc/728/ns
> ....
> ....
> 123749 /home/luser/foo / nfs <whatever>
> root@venus% umount -I 123749
> root@venus% logout
> bastard@venus% mail luser
> Subject: you've been told to umount ~/foo
> <appropriate verbal abus^Weducation>
> ^D
>
> > Avoiding numbers is a good thing. They have no intrinsic meaning.
>
> Tell that to guys who invented file descriptors. IMO that works
> quite fine - I'll prefer to do close(17) rather than <recalling
> incantations of horror needed on OS/360><shuddering><deciding not to
> type that stuff late on Saturday>
But FDs are different. You reference the file by name, and the system
returns an opaque handle. But the system isn't returning a mount ID as
the result of some operation: you had to scan a file for it. So really
your handle to the mount is something else, the mount ID is merely
another level of indirection.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
