Re: [PATCH] private mounts

[Martin Mares <mj@ucw.cz>]

Hi Miklos!

> Is it possible to limit all these from kernelspace?  Probably yes,
> although a timeout for operations is something that cuts either way.
> And the compexity of these checks would probably be orders of
> magnitude higher then the check we are currently discussing.

Yes ... but does the check we are discussing really solve the problem?

Let's say that you attempt to export home directories of users by a user-space
NFS daemon. This daemon probably changes its fsuid to match the remote user,
so the check happily accepts the access and the user is able to lock up the
daemon.

It doesn't seem that there is any simple and universal cure -- root programs
or setuid programs altering their fsuid are just too similar to the real user
programs to separate them cleanly.

I see a lot of similarities with symlinks -- many programs also need to take
extra care of symlinks to be safe. However, symlinks are already senior
citizens of Unix systems and programs know how to cope with them since ages.

Maybe this could be taken advantage of by keeping all user mounts in a separate
directory like /mnt/usr (and /mnt is very likely to be avoided by all programs
traversing directory structure automatically) and symlinking from the requested
mount points there (with symlinks naturally not followed by automatic traversals).

I agree it isn't a neat solution, but it seems to be the first one which is
close to working.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Lisp Users: Due to the holiday, there will be no garbage collection on Monday.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/