Maximum mountpoints + chrooted login

Maximum mountpoints + chrooted login

[Magnus Naeslund(f)]

I was thinking of doing a chrooted login for some ssh accounts.
The plan is this:

put stuff in
/home/u_dev
/home/u_etc
/home/u_bin

Then at login time mount them to
/home/user/dev
/home/user/etc
/home/user/bin
as readonly

chroot to /home/user

...

And then unmount them at logout time.

Does this seem like a bad idea?
(then please tell me why :))

One problem could be the _massive_ mounts, 3*online_users.
Are there any limits/drawbacks doing it like this?
Should i hardlink stuff instead? (worse maintainability).

Just a funny idea i have...
Hit me.

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Maximum mountpoints + chrooted login

[Alexander Viro]

On Wed, 27 Jun 2001, Magnus Naeslund(f) wrote:

> I was thinking of doing a chrooted login for some ssh accounts.
> The plan is this:

[snip CLONE_NAMESPACE-by-hands]
 
> Does this seem like a bad idea?
> (then please tell me why :))

Mostly because there's a better way to do that. Yes, such scheme would
work (that + massive pending fs/super.c cleanups was the main reason why
I didn't go for proper solution in 2.4.0-test*). However, instead of
crufting up kinda-sorta namespaces one could use the real thing. Relevant
cleanups of superblock handling will go in in 2.5.very_early and the
rest of patch (namespace proper) takes about 10Kb.

You can simply say clone(CLONE_NAMESPACE,NULL) and you get an independent
set of mounts to play with. mount/umount whatever you want before dropping
the root priveleges. All children of that process will share its namespace.
When the last one goes away everything will be garbage-collected - no
need to umount anything on logout.

> One problem could be the _massive_ mounts, 3*online_users.
> Are there any limits/drawbacks doing it like this?

With the mntcache in - not really. It fixes the main performance problem.
Memory cost is sizeof(struct vfsmount)*total amount of mountpoints. I.e.
about 100 bytes per mountpoint. That's it.

Re: Maximum mountpoints + chrooted login

[Magnus Naeslund(f)]

From: "Alexander Viro" <viro@math.psu.edu>
>
[snip]
>
> I didn't go for proper solution in 2.4.0-test*). However, instead of
> crufting up kinda-sorta namespaces one could use the real thing. Relevant
> cleanups of superblock handling will go in in 2.5.very_early and the
> rest of patch (namespace proper) takes about 10Kb.
>

I'll wait for 2.5 then...
Where's that namespace patch located?

> You can simply say clone(CLONE_NAMESPACE,NULL) and you get an independent
> set of mounts to play with. mount/umount whatever you want before dropping
> the root priveleges. All children of that process will share its
namespace.
> When the last one goes away everything will be garbage-collected - no
> need to umount anything on logout.
>

Lovely!

>
> With the mntcache in - not really. It fixes the main performance problem.

Now in 2.4.5 it's darn slow to _unmount_, it's like 100 times faster to
mount than unmount :)

Cheers

Magnus Naeslund

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Maximum mountpoints + chrooted login

[Alexander Viro]

On Wed, 27 Jun 2001, Magnus Naeslund(f) wrote:

> I'll wait for 2.5 then...
> Where's that namespace patch located?

The last one I've put on anonftp was against 2.4.6-pre2 (namespaces-a-S6-pre2,
on ftp.math.psu.edu/pub/viro). It still includes tons of fs/super.c cleanups
and fixes - they still need to be merged into the tree.

> Now in 2.4.5 it's darn slow to _unmount_, it's like 100 times faster to
> mount than unmount :)

Erm... The last umount should sync everything on given fs. You don't
read a hundred megabytes upon mount but you can easily get such amount
of dirty data after working for a while ;-)