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
group::r--              #effective:r--
group:install:rw-               #effective:rw-
% 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

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


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to