On Wed, 31 May 2006, André Braga wrote:
A post scriptum to the original message:
The buggy behaviour won't affect the host system, but the jail could well be
compromised. I also have this feeling that ACLs also aren't respected inside
jails or can be overwritten as easily as shown below
By "ACLs also aren't respected inside jails", do you mean, "ACLs don't work in
jail", or do you mean, "ACLs don't work with unionfs"? They are believed
firmly to work with jail, and if you have evidence to the contrary, a PR
pointer would be greatly appreciated so it can be investigated.
I don't know much about the behavior of unionfs, but if VOP_ACCESS is passed
down properly through the stack, then ACLs should be implemented. There might
be problems if two file systems are stacked and have different access control
models. I don't know enough about unionfs to reason about how it does behave,
or should behave. Unionfs seems to violate the notion of POLA, so I'm not
sure how much POLA will help :-).
Robert N M Watson
Thanks,
André
---------------------- 8< ----------------------
Hi,
Once again, thank you for your patch.
I believe I have found a bug:
If a file or directory has non-default flags and this directory is
mounted below a target point, the resulting union will not preserve
the directory flags. Worse, it will appear as if the file flags are
preserved, but they are not and as soon as a file that should not be
modified gets modified, the flags are reset to the default state on
the union mount. This could pose a *serious* security breach for
people running jails rooted on unionfs mounts, like I intended to.
Test case:
(discrepancies are marked by a line containing "**** NOTICE" and
aligned to fixed-length font display)
# cd /tmp
# mkdir -p test/a test/b/bb test/b/cc
# touch test/b/cc/dd
# chflags schg test/b/bb/
# chflags uappnd test/b/cc/dd
# ls -Rlo
total 2
drwxr-xr-x 4 root wheel - 512 Apr 29 08:12 test
./test:
total 4
drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 a
drwxr-xr-x 4 root wheel - 512 Apr 29 08:12 b
./test/a:
total 0
./test/b:
total 4
drwxr-xr-x 2 root wheel schg 512 Apr 29 08:12 bb
**** NOTICE 1a ^^^^ ****
drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 cc
./test/b/bb:
total 0
./test/b/cc:
total 0
-rw-r--r-- 1 root wheel uappnd 0 Apr 29 08:12 dd
**** NOTICE 2a ^^^^^^ ****
# echo ee >test/b/cc/dd
test/b/cc/dd: Operation not permitted.
# echo ee >> test/b/cc/dd
**** NOTICE: this is the intended behavior for the 'uappnd' flag ****
# cat test/b/cc/dd
ee
#
# mount_unionfs -c transparent -b test/b test/a
# ls -Rlo
total 2
drwxr-xr-x 4 root wheel - 512 Apr 29 08:12 test
./test:
total 4
drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 a
drwxr-xr-x 4 root wheel - 512 Apr 29 08:12 b
./test/a:
total 4
drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 bb
**** NOTICE 1b ^^^ ****
drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 cc
./test/a/bb:
total 0
./test/a/cc:
total 2
-rw-r--r-- 1 root wheel uappnd 3 Apr 29 08:15 dd
**** NOTICE 2b (LOOKS OK) ^^^^^^ ****
./test/b:
total 4
drwxr-xr-x 2 root wheel schg 512 Apr 29 08:12 bb
drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 cc
./test/b/bb:
total 0
./test/b/cc:
total 2
-rw-r--r-- 1 root wheel uappnd 3 Apr 29 08:15 dd
# echo ff > test/a/cc/dd
# cat test/a/cc/dd
ff
**** NOTICE: very wrong behavior for the 'uappnd' flag! ****
# ls -lo test/a/cc/dd
-rw-r--r-- 1 root wheel - 3 Apr 29 08:20 test/a/cc/dd
**** NOTICE 2c (NO FLAG!) ^^^ ****
# echo gg >test/b/cc/hh
# chflags schg test/b/cc/hh
# rm test/b/cc/hh
override rw-r--r-- root/wheel schg for test/b/cc/hh? yes
rm: test/b/cc/hh: Operation not permitted
**** NOTICE 3a ^^^^^^^^^^^^^^^^^^^^^^^ ****
# ls -lo test/a/cc/hh
-rw-r--r-- 1 root wheel schg 3 Apr 29 08:24 test/a/cc/hh
**** NOTICE 3b ^^^^ ****
# rm test/a/cc/hh
override rw-r--r-- root/wheel schg for test/a/cc/hh? yes
**** NOTICE 3c (NO ERROR!) ****
# ls -lo test/a/cc/
total 2
-rw-r--r-- 1 root wheel - 3 Apr 29 08:20 dd
**** NOTICE 3d (the file is gone despite immutable flags seemingly set!)
****
End of test case
It makes no difference to specify '-c tradicional'.
I skimmed over the patch code and have noticed no file flags or
director[y flags] are indeed [ever] copied to the shadow files.
[Edit: spelling]
I'd really appreciate if you could fix that for the patch version 12.
Thank you very much!
André
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
