Re: [PATCH] Minor sys_umount fix (changes semantics slightly)

Malcolm Beattie (mbeattie@sable.ox.ac.uk)
Fri, 17 Dec 1999 12:43:04 +0000 (GMT)


H. Peter Anvin writes:
> What *is* important, however, is to
> have umount(8) accept what is given to mount(8), even when the "user"
> option is enabled etc.
>
> There is also a race condition in mount/umount when using the "user"
> option. The most sensible way of fixing it seems to be to have
> fmount/fumount.

Here is a mixture of replies to various points made in this thread.
For the above, fmount/fumount is a separate issue in that such a
syscall is no use for my particular situation (for the same reason
that flstat doesn't exist :-). My second patch keeps all current
behaviour exactly the same for both the umount syscall and the
userland umount executable plus it allows both to work fine with my
fs. What the second patch does is to make sys_umount check first to
see if the passed in filename (without following symlinks) is itself
a mountpoint. (This will be true if and only if it's a symlink-root fs
like mine is: no current fs will match this condition). If so, it
umounts. If not, it falls back to following the symlink and the
behaviour is the same as before for everything.

For the person who askes why have such a filesystem: it's part of my
Mandatory security policy/MAC/MLS/CMW/B1-ish/other acronym patches to
Linux. Tasks (in the Linux sense, i.e. processes/threads) each have a
mac_label which determines which compartment they live in. If you do
for example
mlsmount /tmp/mls /tmp/mls /tmp/mls/clientfoo /tmp/mls/clientbar
then it's equivalent to getting file descriptors 10 and up for all
except the first arg and then execing
mount -t mls -o fd=10:11:12 none /tmp/mls
the filesystem keeps an array of the dentries corresponding to those
descriptors in its superblock. The root inode (the only inode in the
filesystem) shows itself as a symlink, the readlink method returns the
fixed string "[MLS]". The follow_link method takes the compartment
section of the current task's mac_label, indexes into the array of
dentries and returns that. So compartment 0 (the compartment which can
see the whole system (modulo the other parts of the mac_label
permitting it)) looks in /tmp/mls to find the same as the original
one, complete with subdirectories clientfoo and clientbar. For tasks
in compartment 1, /tmp/mls is really /tmp/mls/clientfoo and for tasks
in compartment 2, /tmp/mls is really /tmp/mls/clientbar. (Within a
compartment, you can't tell where you "really" are, of course). Such
games for /etc let you have separate "virtual machines" running in
different compartments with no userland changes. Currently, I have the
basics working but the networking side is "interesting" and not fully
done yet. I'll make patches available now if enough people are
interested, otherwise I'll wait until January.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

- 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/