Maximum mountpoints + chrooted login
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Quoted 2 lines · Magnus Naeslund(f)
I was thinking of doing a chrooted login for some ssh accounts. The plan is this:
[snip CLONE_NAMESPACE-by-hands]
Quoted 2 lines
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.
Quoted 2 lines
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.
From: "Alexander Viro" <[email protected]>
Quoted 1 line
[snip]
Quoted 6 lines
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?
Quoted 3 lines
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.
Quoted 3 lines
When the last one goes away everything will be garbage-collected - no need to umount anything on logout.
Lovely!
Quoted 2 lines
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Quoted 2 lines · Magnus Naeslund(f)
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.
Quoted 2 lines
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 ;-)