[PVFS-developers] Possible permissions handling bug

[Nathan Poznick]

--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Hello all,

We're having a bit of a problem, and it appears that it may be due to a
bug in the handling of permissions in the PVFS code.  So, I'd like to
describe the problem and see what everyone else thinks.

We're currently using PVFS 1.6.0-pre1, with the VFS interface through
the kernel module.

Disclaimer:  We use LDAP for storing user information, but I don't think
that enters into this issue, since we have ensured that the manager can
resolve all userids, groups, etc.

This first part is a description of how things work on local
filesystems, and on NFS filesystems.

Assume two users:
mtalle, and npozni

Assume three groups:
mtalle, npozni, and testgrp

Both mtalle and npozni have their default group set to a group of the
same name.  Thus, mtalle's default group is mtalle, and npozni's default
group is npozni.  Both mtalle and npozni also belong to the testgrp
group.

Assume a directory called testdir, with an owner of mtalle, and a group
of testgrp.  Permissions are set to 0770.

drwxrwx---    1 mtalle   testgrp         0 Aug  1 10:28 testdir

The user npozni enters the testdir directory, and creates a file:

npozni@dpdred2:/u01/testdir$ ls -l > file
npozni@dpdred2:/u01/testdir$ ls -l =20
total 4
-rw-r--r--    1 npozni   npozni         69 Aug  1 10:46 file

Then, the user changes the group ownership of the file to 'testgrp':

npozni@dpdred2:/u01/testdir$ chgrp testgrp file=20
npozni@dpdred2:/u01/testdir$ ls -l
total 4
-rw-r--r--    1 npozni   testgrp        69 Aug  1 10:46 file

Then, for good measure, the user overwrites the file:

npozni@dpdred2:/u01/testdir$ ls -l > file=20
npozni@dpdred2:/u01/testdir$ ls -l
total 4
-rw-r--r--    1 npozni   testgrp        69 Aug  1 10:49 file

On a local filesystem, and on NFS, that works as expected.  However, on
PVFS, the user is unable to change the group ownership of the file, and
is unable to overwrite the file, once it is in place.  This ONLY seems
to happen when the owner of the directory is NOT the user creating the
file / doing the chgrp / overwriting the file.

On PVFS we see this behavior:

npozni@dpdred2:/mnt/pvfs/testdir$ ls -l > file
npozni@dpdred2:/mnt/pvfs/testdir$ ls -l
total 1
-rw-r--r--    1 npozni   npozni         69 Aug  1 10:53 file
npozni@dpdred2:/mnt/pvfs/testdir$ chgrp testgrp file=20
chgrp: changing group of `file': Permission denied
npozni@dpdred2:/mnt/pvfs/testdir$ ls -l > file
bash: file: Permission denied

Again, this only seems to occur when a different user is the owner of
the directory:

drwxrwx---    1 mtalle   testgrp         0 Aug  1 10:53 testdir

If the owner of the directory is the user doing the work, there are no
problems.

Without looking too deeply, I'm led to believe that there might be a
semantics issue with meta_access() and/or meta_check_ownership() (or
their use in other places in the manager code).

Any thoughts?


Thanks,
Nathan

--=20
Nathan Poznick <poznick@conwaycorp.net>

Cross country skiing is great if you live in a small country. -Stephen
Wright


--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KpDjYOn9JTETs+URAkPgAKCtrUp+H9roR7iNKmlc08FSDKRpFACgjkA9
bBg3TDhuQW2uUht06FYVb/g=
=4nKL
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--