setfacl man page states "d=delete_child" and "D=delete"

[Harald Schmalzbauer]

 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 needed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130208/c3ba1d7c/attachment.sig>