From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 24 Nov 2003 - 14:14:23 GMT
On Mon, Nov 24, 2003 at 12:29:09PM +0100, Ake van der Meer wrote:
> Hi Herbert,
>
> >From linux-vserver.org it wasn't obvious to me how to best file a
> problem or bug report.
currently, the best way is via the mailing list ...
> Last weekend I upgraded several machines from ctx17 to vs1.00, and saw
> Amanda backups breaking.
>
> I found the following underlying issue:
>
> On regular hosts as well as with at least ctx17, root can read files and
> enter directories regardless of actual permissions.
>
> In a vs1.00 virtual server, root can't.
there is a bunch of capabilities controlling this
behaviour, and those capabilities are given to
a vserver even with --secure.
CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER
CAP_FS_MASK ...
I'm sure that this hasn't changed with the kernel
patch, but maybe the userspace tools changed
something not obvious.
here a short test I did with 2.4.22-vs1.00
# mkdir /tmp/XXX
# chmod 700 /tmp/XXX
# echo "five" >/tmp/XXX/a
# chmod 500 /tmp/XXX/a
# chown -R 100.100 /tmp/XXX
# chcontext --secure --ctx 100 ls -la /tmp/XXX/
New security context is 100
total 3
drwx------ 2 100 users 1024 Nov 24 13:59 .
drwxrwxrwt 3 root root 1024 Nov 24 13:58 ..
-r-x------ 1 100 users 5 Nov 24 13:59 a
# chcontext --secure --ctx 100 cat /tmp/XXX/a
New security context is 100
five
so it seems to me that this _is_ working as
expected on vs1.00 with util-vserver 0.24/0.25/0.26
> Amanda can use GNU tar to make backups, and tar will signals an error
> when it can't enter a directory or read a file, causing Amanda to fail
> the backup. (Try "cd /tmp; mkdir xyz; chmod 0 xyz; tar cf /dev/null xyz"
> to see the error.)
>
> The upshot is that any unprivileged user can now cause backups to fail
> due to this difference in permission semantics.
>
> Likely it will cause problems in other scenarios as well.
maybe you can try to 'create' a simple, reproducible
scenario, which shows this behaviour for your setup,
probably without even starting a vserver (as in the
example above) so I can recreate/reproduce it ...
> I haven't tested the latest development release for this behaviour, it
> is alas non-trivial for me to do so. I see nothing in the ChangeLog to
> indicate that this behaviour has changed.
>
> Will you consider reverting to vserver's old behaviour on this point?
if there has been a change, which breaks tar within
a vserver, I consider it a bug, and I will try to
fix/eliminate it ...
> Thank you for letting me bring this to your attention.
well, thank you for reporting back your findings,
development alway depends on feedback ...
TIA,
Herbert
> Kind regards,
> Ake.
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver