From: Ivo De Decker (ivo_at_zeus.rug.ac.be)
Date: Sat 23 Nov 2002 - 08:52:35 GMT
Hello,
I did some testing with the vserver-quota-patches
(http://www.13thfloor.at/VServer/). Some remarks...
About capabilities:
from linux-2.4.20rc2-ctx14-vquota-0.10.diff:
+/* Allow changing context information */
+
+#define CAP_CHCTX 30
+
+/* Allow quotactl */
+
+#define CAP_QUOTACTL 31
from linux-2.4.20rc2-ctx14-vroot01.diff:
+/* Allow quotactl */
+
+#define CAP_QUOTACTL 30
+
It's unfortunate that the number for CAP_QUOTACTL is different in both
patches. The obvious solution would be to give CAP_CHCTX number 31 instead.
After that, we can ask Jacques to include CAP_QUOTACTL in the main vserver
patch/tools.
Can you explain the use of these extra CAPs (on your webpage)?
If I'm correct, CAP_QUOTACTL allows the user to read and change
quota-information on all available devices.
(a trick to give read-only access to quota: the root user in a vserver can
allways read the quota-information for another user by doing setuid(), no
special extra capability (other than CAP_SETUID) is required to do that.)
Is it correct that only 32 capabilities can be defines in the current kernel?
That would mean that we are running out of caps. Is there an easy way to
increase the number? (ie would it break other stuff to increase the number)
The vroot patch seems to work just fine. In the patch you define the major
number for the vroot device to be '4'. The same number is used as major number
for tty devices. Is this a security risk? (a vserver with tty devices could
read/set quota on the corresponding vroot device, which could belong to
another vserver; and a vserver with a vroot device could use the corresponding
tty device, which is probably used by the root server)
Some remarks about context quota:
When the patch is applied, the uid/gid change of files inside a vserver
happens automatically. It would be nice if this could be turned on/off.
There are no userspace tools to see/change the ctx-id of a file. (I'm sure
it's on the todo list ;-)
(a trick to change the ctx-id of all files inside a vserver from 0 to the ctx
number of the vserver, is to recursively chown/chgrp every file to the same id
inside the vserver)
If the ctx id of a vserver changes, things get really bad: the files appear to
be owned by a normal user, but any changes results in 'permission denied'.
This should not happen (if you use the context quota patch you have to use
fixed ctx ids; I don't know if this is stated clearly on the webpage), but if
it happens, there's no easy fix.
A cosmetic bug in the quotatools patch:
When 'quota' displays context quota for id x, the name for the user with id x
is showed instead of the vserver name (the quick fix would be to display no
name at all).
In the howto on the website you talk about LVM, but there's no link to
documentation about LVM.
And finally some step to follow when trying to debug vserver-quota:
First of all, make sure that the kernel-patch en the patch for the userspace
tools work together! This means that when you download a new kernel patch, you
allway have to update the userspace tools as well. Forgetting this can result
in strange problems, that are difficult to debug (been there...).
Make sure you install the right quota tools in the root server and in the
vserver.
If you followed the instructions on the website, but 'quota' doesn't work, you
can try to get it working in 3 stages:
1) quota in the root server
First of all, make sure everything works in the root server. If it doesn't
work there, there's no way it will work in the vserver. In general, the
standard quota documentation should be enough to fix that.
2) quota in a chroot (not the vserver)
If it works in the root server, try to chroot into the vserver directory (this
is not the same as using 'vserver enter': you keep all capabilities when you
do this).
If quota doesn't work from inside the chroot:
- check /etc/mtab (in the vserver); Make sure the quota options (usrquota,
grpquota, ctxquota) are mentioned!
- check if the device exists inside the vserver. If not, create it.
!!! WARNING !!!
Creating the real device inside the vserver is a security risk:
the vserver root can use this to read/write to the disk
Try using vroot instead.
- if you are using vroot, try creating the real device inside the vserver, and
adapt /etc/mtab. (This is for testing only! Remember to delete the device
and change mtab back to vroot once everythink works file)
If it works with the real device, but not with the vroot device, make sure
your vroot setup is correct.
3) quota inside the vserver
Once quota works inside a chroot, it shouldn't be too difficult to get it
working inside the vserver. The only read difference is the capability
reduction:
If you can only read quota for your current uid/gid, you need to enable
CAP_QUOTACTL in the vserver config.
If you can't get it working, try 'strace quota' and find out where it goes
wrong. In some cases, quota will try to read the quota files itself instead of
using the kernel calls (this happens when the kernel calls return an error).
In that case, quota will misteriously fail inside the chroot, but not in the
root server, but in fact it isn't working correctly there either. This can
happen if you use the wrong userspace tools for the kernel.
I hope these remarks are usefull. If you update the quota-patches, I will be
happy to test them again...
Greetings,
Ivo De Decker