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 [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
