Date: Mon, 20 Aug 2012 15:26:32 +0300 From: =?UTF-8?B?0J/QsNCy0LXQuw==?= <pavel.priv@hte.vl.net.ua> To: =?UTF-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= <trasz@FreeBSD.org> Cc: freebsd-fs@freebsd.org Subject: Re: Some of ZFS ACLs doesn't work as expected Message-ID: <50322CF8.8000105@hte.vl.net.ua> In-Reply-To: <788B90E6-B36B-40D3-8C89-BD1A2902D4D5@FreeBSD.org> References: <502FD583.9070105@hte.vl.net.ua> <06453437-D034-41C2-8B7F-15B228AD2532@FreeBSD.org> <503128BB.6040801@hte.vl.net.ua> <788B90E6-B36B-40D3-8C89-BD1A2902D4D5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
20.08.2012 14:53, Edward Tomasz Napierała пишет: > Wiadomość napisana przez Pavel Bychykhin w dniu 19 sie 2012, o godz. 19:56: >> 19.08.2012 19:40, Edward Tomasz Napierała пишет: >>> Wiadomość napisana przez Pavel Bychykhin w dniu 18 sie 2012, o godz. 19:48: >>>> Dear community! >>>> >>>> After my experiments with ZFS, I concluded, that permissions "delete_child" and "delete" are ignored. >>>> For the create/update/delete operation a list of "rwxp" (read_data/write_data/execute/append_data) is fully sufficient. >>> They are not ignored, but yes, write access on a directory is enough to delete a file. >>> >>>> No need to specify the "delete_child" and "delete" permissions at all, or I don't understand something? >>> Unless you need them - no, you don't. That's why these bits are not set in a default >>> case (so called 'trivial ACL', i.e. no ACL set on a file). >>> >> Could you please provide an example of at least one practical situation, where the "delete_child" and "delete" permissions would be useful? > You could allow for file creation, but deny file removal. Still, as someone > already mentioned, main reason for these to exist is compatibility with Windows > and NFSv4 spec. It's just that they are not _completely_ ignored, like SYNCHRONIZE > or READ_XATTR/WRITE_XATTR are. > Now I understand. This is only for "deny" rules. Thanks a lot.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50322CF8.8000105>