From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 15:13:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B70D953 for ; Fri, 8 Feb 2013 15:13:49 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 16978B57 for ; Fri, 8 Feb 2013 15:13:48 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r18FDthG092166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2013 16:13:55 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <511514F5.4010504@omnilan.de> Date: Fri, 08 Feb 2013 16:08:37 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: setfacl man page states "d=delete_child" and "D=delete" X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5CF0A444F77C183B6F4F11CB" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 15:13:49 -0000 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--