Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 08 Feb 2013 16:08:37 +0100
From:      Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
To:        freebsd-stable@freebsd.org
Subject:   setfacl man page states "d=delete_child" and "D=delete"
Message-ID:  <511514F5.4010504@omnilan.de>

next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5CF0A444F77C183B6F4F11CB
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

 Hello,

I think there's a confusion in the man page setfacl(1).

In my tests, "D" means "delete_child" and "d" "delete"; like it's true
for other NFSv4 implementations. But manpage tells the other way around.

Since things didn't work as expected when I followed the man page I
checked the following as a member of group "intern":
1st test, following the man page, this acl should prevent users of group
"intern" to delete anything inside "testdir":

    >: getfacl testdir
# file: testdir/
# owner: root
# group: intern
            owner@:rwxp--aARWcCos:------:allow
            group@:rwxp--a-R-c--s:------:allow
            group@:-----d--------:------:deny
         everyone@:------a-R-c--s:------:allow

    >: ls -l testdir
total 3
drwxr-xr-x  2 root  intern  2  8 Feb 15:38 2nd
-rw-r--r--  1 root  intern  0  8 Feb 15:44 testfile

But:
    >: rm testdir/testfile
override rw-r--r--  root/intern for testdir/testfile? y

    >: ls -l testdir
total 2
drwxr-xr-x  2 root  intern  2  8 Feb 15:38 2nd

*pow*
"testfile" of directory testdir got unlinked, since write permission to
"testdir" has overridden group-readonly of "testfile" and no
"delete_child" restriction took place.

2nd test, using "D" instead of "d":
    #: setfacl -m group@:D::deny shared/testdir

    >: getfacl testdir
# file: testdir
# owner: root
# group: intern
            owner@:rwxp--aARWcCos:------:allow
            group@:rwxp--a-R-c--s:------:allow
            group@:----D---------:------:deny
         everyone@:------a-R-c--s:------:allow

    >: ls -l testdir
total 3
drwxr-xr-x  2 root  intern  2  8 Feb 15:38 2nd
-rw-r--r--  1 root  intern  0  8 Feb 15:55 testfile

    >: rm testdir/testfile
override rw-r--r--  root/intern for testdir/testfile? y
rm: testdir/testfile: Operation not permitted

    >: ls -l testdir
total 3
drwxr-xr-x  2 root  intern  2  8 Feb 15:38 2nd
-rw-r--r--  1 root  intern  0  8 Feb 15:55 testfile


Shall I file a PR? Or do I completely misunderstand things?

Thanks,

-Harry

P.S.: Btw., can anybody explain me why (at some time, someone decided
that) write permission to a directory does override file permissions
inside the directory? I can't get the sense.  Of course, there's the
sticky bit, but that's not inheritable. I can't imagine why the stick
bit doesn't work inverted. The default behaviour should be like with
sticky bit set, and by setting something like the sticky bit,
optionally, one can empower the directory write permitted users/groups
to override file-permissions inside. That's the only thing I'd ever neede=
d.


--------------enig5CF0A444F77C183B6F4F11CB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAlEVFQEACgkQLDqVQ9VXb8gLtgCgkbXc69OnQH06p8H7f1kVW7oj
HSMAn1i4NMkH/y8s6HB4mSmI6xPSJE/B
=Otz+
-----END PGP SIGNATURE-----

--------------enig5CF0A444F77C183B6F4F11CB--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511514F5.4010504>