Inconsistencies in *stat() for files with ACLs
Hi, lstat(), fstat(), stat() returned structure is inconsistent and misleading if the file has ACLs associated with it. Example: % getfacl test #file:test #owner:0 #group:4004 user::rw- group::r-- group:wheel:rw- mask::rw- other::r-- So the file has permissions rw-r--r--, but an additional group wheel has write permissions. But ls output suggests: % ls -l test -rw-rw-r-- 1 root rock 4 2 Dez 21:00 test that the primary group has these write permissions. But: % id uid=4024(rock) gid=4004(rock) % echo test test test: Permission denied. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Inconsistencies in *stat() for files with ACLs
On Sun, 2 Dec 2001, Daniel Rock wrote: Hi, lstat(), fstat(), stat() returned structure is inconsistent and misleading if the file has ACLs associated with it. That behavior is defined by POSIX.1e, so it's what we implemented; you'll find that the same behavior is present on other platforms with conforming implementations. It actually does make some sense, when you think about it: POSIX.1e requires that the group permissions returned by stat() be the ACL_MASK entry if an extended ACL is present. That means that stat() displays the worst case protections. Likewise, the spec requires that chmod() modify the ACL_MASK entry if an extended ACL is present, which gives you conservative behavior: if group write is removed, the right thing happens. For example, if you chmod 0600 on the file, it works: POSIX.1e considers the extended ACL to expand the group entry of the permissions. That said, I won't argue it's intuitive unless you know about the behavior already, and it probably should be documented in the stat(2) man page. If you're interested in discussing these semantics, it might be worth raising it on the POSIX.1e mailing list ([EMAIL PROTECTED]). A number of people involved in writing the spec are there, and in the past it has been a successful forum for discussing ambiguities (not to mention mistakes) in the spec. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Inconsistencies in *stat() for files with ACLs
Robert Watson schrieb: On Sun, 2 Dec 2001, Daniel Rock wrote: Hi, lstat(), fstat(), stat() returned structure is inconsistent and misleading if the file has ACLs associated with it. That behavior is defined by POSIX.1e, so it's what we implemented; you'll find that the same behavior is present on other platforms with conforming implementations. I can only check it with Solaris (Solaris 8). Solaris' output of lstat() is just what I would expect: % getfacl bla # file: bla # owner: root # group: rock user::rw- group::r-- #effective:r-- group:install:rw- #effective:rw- mask:rwx other:r-- % ls -l bla -rw-r--r--+ 1 root rock 2 Dez 3 01:26 bla and lstat(bla, st) returns st.st_mode = 0100644 - but group install has write permissions. But according to standards(5) Solaris 8 doesn't claim to be POSIX.1e compliant. I'll give Solaris 9 a try. It actually does make some sense, when you think about it: POSIX.1e requires that the group permissions returned by stat() be the ACL_MASK entry if an extended ACL is present. That means that stat() displays the worst case protections. Likewise, the spec requires that chmod() modify the ACL_MASK entry if an extended ACL is present, which gives you conservative behavior: if group write is removed, the right thing happens. For example, if you chmod 0600 on the file, it works: POSIX.1e considers the extended ACL to expand the group entry of the permissions. Intuitive would be: stat() returns the primary group in st_gid and no additional groups. So I'd expect st_mode match permissions of this specific group. That said, I won't argue it's intuitive unless you know about the behavior already, and it probably should be documented in the stat(2) man page. If you're interested in discussing these semantics, it might be worth raising it on the POSIX.1e mailing list ([EMAIL PROTECTED]). A number of people involved in writing the spec are there, and in the past it has been a successful forum for discussing ambiguities (not to mention mistakes) in the spec. I don't have access to the POSIX spec. I only found some early drafts. Without detailed knowledge of these internals I wouldn't be a good participant in this discussion. But what about some additions to ls: In Solaris - if the file has additional ACLs - the permissions are followed by a plus sign (see above). So you know: To get full information you have to use getfacl. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Inconsistencies in *stat() for files with ACLs
On Mon, Dec 03, 2001 at 01:52:19AM +0100, Daniel Rock wrote: Robert Watson schrieb: That said, I won't argue it's intuitive unless you know about the behavior already, and it probably should be documented in the stat(2) man page. If you're interested in discussing these semantics, it might be worth raising it on the POSIX.1e mailing list ([EMAIL PROTECTED]). A number of people involved in writing the spec are there, and in the past it has been a successful forum for discussing ambiguities (not to mention mistakes) in the spec. I don't have access to the POSIX spec. I only found some early drafts. Without detailed knowledge of these internals I wouldn't be a good participant in this discussion. See http://wt.xpilot.org/publications/posix.1e/download.html for .pdf's, .ps's, and .nroff's of the last drafts (.1e and .2c). http://www.TrustedBSD.org/ also has links to the posix1e mailing lists and other resources. But what about some additions to ls: In Solaris - if the file has additional ACLs - the permissions are followed by a plus sign (see above). So you know: To get full information you have to use getfacl. See http://www.fxp.org/jedgar/ACL/ for patches to enable ACL support for cp, ls, and mv. For ls, the patch simply changes the string obtained from stat(2). In the future stat(2)/strmode(3) will support ACL's natively. Also, I committed a patch recently to the gnuls port to give it support ala the aformentioned ls patch. -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org msg32675/pgp0.pgp Description: PGP signature
