From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Sat 13 Jul 2002 - 06:27:28 BST
On Fri, 12 Jul 2002 15:25:41 0100, Sam Vilain wrote
> Jacques Gelinas <jack_at_solucorp.qc.ca> wrote:
>
> > > Quota works fine if each vserver is mounted on a different LVM share, or
> > > loopback filesystem.
> > Yes but there is another issue. You may want to limit quota per user in
> > a vserver and allow the vserver administrator to handle it. To handle quota
> > he needs access to the block device and this opens a security issue.
>
> Is it much of a security issue to give them a /dev entry for their own LVM partition?
At first tought, I would say no
> I guess the answer is yes, a malicious user could hang the kernel by frigging with
> the block device themselves.
Yep you are right. local file system drivers (ext2, name it) all assume the file system
is clean, so one can corrupt the fs by writing to the device and then just access
some file and the kernel will go wild.
> But if it was there, but they just couldn't open it, they could still call quotactl()
> on it and quotas would still work. Is this your intention for the new unused CAP_OPENDEV
> capability?
Not exactly. Capability are no so good in that case because it is an all or nothing. We
could have a capability to prevent some operation on block device and then operation
of char device, but this is too harsh. We could also have an extended bit on the file
as well.
Another solution would be to do something like
ln -s /proc/mydisk /dev/hdv1
and have mydisk as a magic device (a little like /dev/tty) filtering some commands
and passing other to the real disk. Now a vserver may span several disk, so we
may need something more intelligent.
Some application play directly with the quotactl system call. Very few.
One possibility would be to modify those to use a proxy thing a little like
vreboot is doing. I don't like it, because it means changing apps here and there
(although for a very special purpose) like freevsd.
Another solution is a devfs like thing to replace our little /dev.
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc