On Thu 2008-05-29 01:12:23 -0400, Daniel Kahn Gillmor wrote: > Attached is the test program that displays this behavior. It should > fail with "write lock failed: Permission denied" when used on a file > on a CIFS mount, and it has succeeded quietly on every other > filesystem i've tried.
In particular, the test program even succeeds (with the exception of
NFSv3) on non-cifs filesystems mounted with the "mand" option, and
with files whose mode was set with chmod g+s,g-x, which i believe is
the documented way to turn on mandatory locking [0].
here's it working on a tmpfs mounted with mand:
[0 [EMAIL PROTECTED] ~]$ grep mnt /proc/mounts
/root/foo /mnt tmpfs rw,mand 0 0
[0 [EMAIL PROTECTED] ~]$ echo -n a > /mnt/foo
[0 [EMAIL PROTECTED] ~]$ chmod g+s,g-x /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ls -la /mnt/foo
-rw-r-Sr-- 1 dkg dkg 1 2008-05-29 15:56 /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ~/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 [EMAIL PROTECTED] ~]$
and here's an ext3 fs mounted with mand:
[0 [EMAIL PROTECTED] ~]$ grep mnt /proc/mounts
/dev/mapper/squeak0-tester /mnt ext3 rw,mand,data=ordered 0 0
[0 [EMAIL PROTECTED] ~]$ echo -n a > /mnt/foo
[0 [EMAIL PROTECTED] ~]$ chmod g+s,g-x /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ls -la /mnt/foo
-rw-r-Sr-- 1 dkg dkg 1 2008-05-29 15:59 /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ~/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 [EMAIL PROTECTED] ~]$
and vfat (i couldn't set the group setuid bit on vfat, but the test
program still worked):
[0 [EMAIL PROTECTED] ~]$ grep mnt /proc/mounts
/dev/mapper/squeak0-tester /mnt vfat
rw,mand,uid=1000,gid=1000,fmask=0033,dmask=0022,codepage=cp437,iocharset=iso8859-1
0 0
[0 [EMAIL PROTECTED] ~]$ echo -n a > /mnt/foo
[0 [EMAIL PROTECTED] ~]$ chmod g+s,g-x /mnt/foo
chmod: changing permissions of `/mnt/foo': Operation not permitted
[1 [EMAIL PROTECTED] ~]$ ~/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 [EMAIL PROTECTED] ~]$
and xfs with mand:
[0 [EMAIL PROTECTED] ~]$ grep mnt /proc/mounts
/dev/mapper/squeak0-tester /mnt xfs rw,mand,ikeep,noquota 0 0
[0 [EMAIL PROTECTED] ~]$ echo -n a > /mnt/foo
[0 [EMAIL PROTECTED] ~]$ chmod g+s,g-x /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ls -la /mnt/foo
-rw-r-Sr-- 1 dkg dkg 1 2008-05-29 16:07 /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ~/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 [EMAIL PROTECTED] ~]$
However, on NFSv3 (exported from an up-to-date etch nfs-kernel-server
with (rw,subtree_check), and mounted with all kinds of different
options (with and without mand), my little test program continually
fails *at the read lock* stage if the file is mode g+s,g-x:
[0 [EMAIL PROTECTED] ~]$ grep mnt /proc/mounts
bob:/srv/dmz /mnt nfs
rw,vers=3,rsize=32768,wsize=32768,hard,nointr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=192.168.2.99
0 0
[0 [EMAIL PROTECTED] ~]$ ls -la /mnt/foo
-rw-r--r-- 1 dkg dkg 1 2008-05-29 17:04 /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ~/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 [EMAIL PROTECTED] ~]$ chmod g+x /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ~/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 [EMAIL PROTECTED] ~]$ chmod g+s /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ~/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 [EMAIL PROTECTED] ~]$ chmod g-x /mnt/foo
[0 [EMAIL PROTECTED] ~]$ ~/src/cmrg/test/testlocking/testlocking /mnt/foo
read lock failed: No locks available
[1 [EMAIL PROTECTED] ~]$
so, interestingly, the nfs client appears to think that the mode bits
alone are sufficient to indicate mandatory (as opposed to advisory)
locking, and it apparently knows that NFSv3 is incapable of providing
mandatory locks.
At any rate, the behavior of cifs with the brl option is clearly
divergent from the behavior of the other filesystems.
--dkg
[0] from fcntl(2):
To make use of mandatory locks, mandatory locking must be enabled both
on the file system that contains the file to be locked, and on the file
itself. Mandatory locking is enabled on a file system using the "-o
mand" option to mount(8), or the MS_MANDLOCK flag for mount(2). Manda-
tory locking is enabled on a file by disabling group execute permission
on the file and enabling the set-group-ID permission bit (see chmod(1)
and chmod(2)).
pgpUoci7qyTPA.pgp
Description: PGP signature
