freebsd stable - Feb 2013 - setfacl man page states "d=delete_child" and "D=delete"

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>

Wiadomo?? napisana przez Harald Schmalzbauer w dniu 8 lut 2013, o godz.
16:08:
> 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.
Fixed the man page, thanks!

[..]
> 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?
Not sure what you mean here.  If you're asking why having write permission
to the directory gives the ability to remove files inside that directory,
despite not having write permission to the files themselves - well, that's
how it always worked.  I guess the rationale is that when you remove a file,
you're modifying (writing) the directory, not the file contents.

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?