From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Sat 23 Nov 2002 - 14:32:09 GMT
On Sat, Nov 23, 2002 at 09:52:35AM +0100, Ivo De Decker wrote:
> 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.
you are absolutely right about that, I will change
it in the next release ...
> 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.
... to read and change quota of an other realm/context.
> (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.)
CAP_SYS_ADMIN is currently sufficient for complete
quota control, CAP_QUOTACTL enables root in a virtual
server to maintain the user quotas.
maybe I'll drop the CAP_QUOTACTL anyway, and allow
virtual root to administer the users per se.
> 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)
I guess it should not be hard to change from __u32 to __u64
in the capability structures/definitions. Will it break
something? I don't know!
> 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
the vroot device is a block device, where the tty is a
character one, so these go well side by side, for example
block 3 is ide, where character 3 is tty-slaves ...
> 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)
... so no, this could not happen.
> 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.
hmm, why would you like to turn it off?
this would be some sort of defeating the purpose, wouldn't it?
the idea is not-to-change everything to the context,
and use unification for files never changed within the
virtual context (these files stay within context 0)
> There are no userspace tools to see/change the ctx-id of a file. (I'm sure
> it's on the todo list ;-)
in context 0/1 you'll see the context/uid/gid combination
which "contains" the context shifted left by 16.
for example ctx=2, uid=3 will show id 2*65536+3
> (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)
you can also use chown XXX:YYY to set uid/gid in context 0
to any 32bit value, where the lower 16 bits will go to
the uid/gid and the high 16 bits will go to the context.
a perl tool could be written to simplify the math.
> 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 is intentional. (inter context security)
> 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.
yes of course, you can chown the files back to the
root server (ctx 0) so everything is fine again.
but you are right, context quota only makes sense
with fixed context ids.
> 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).
I'll check that, because I already fixed that once, but
maybe I didn't include it in the latest release ...
> In the howto on the website you talk about LVM, but there's no link to
> documentation about LVM.
I will add some links shortly ...
> And finally some step to follow when trying to debug vserver-quota:
do you have a place on the web to put these notes/hints?
If so, I would be glad to link to them, otherwise I will
include your information when I find some spare time.
> 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...
I'm happy to get some response, because bugs can be
found and fixed without feedback, bad/insufficient
documentation can't.
best,
Herbert
> Greetings,
>
> Ivo De Decker
>
>