bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ls vs. Solaris 10: all files get "+" alternate access method flag


From: Jim Meyering
Subject: ls vs. Solaris 10: all files get "+" alternate access method flag
Date: Thu, 01 Mar 2007 22:30:47 +0100

Yesterday, Nelson Beebe tested coreutils-6.8+.

I replied:
> "Nelson H. F. Beebe" <address@hidden> wrote:
> ...
> > I have a question, however.  Since 6.8 got installed, I've been
> > seeing a + at the end of the permission field, e.g., on abajo:
> >
> > % ls -l /usr/local/share/man/man3cw/urcw4.3cw
> > -rw-rw-r--+ 1 beebe wheel 1638 2007-02-26 22:57
> > /usr/local/share/man/man3cw/urcw4.3cw
> >
> > This is not documented in the man page for ls, but a search
>
> Remember that coreutils man pages are usually little more than
> massaged --help output.  In the real documenatation (info coreutils),
> this is documented:
>
>      Following the permission bits is a single character that specifies
>      whether an alternate access method applies to the file.  When that
>      character is a space, there is no alternate access method.  When it
>      is a printing character (e.g., `+'), then there is such a method.
>
> > of the source code shows that the + is attached when there
> > is an ACL.  The thing is, there should be no ACLs on these
> > files.  Here is what the ACL utility reports:
> >
> > % getfacl /usr/local/share/man/man3cw/urcw4.3cw
> > getfacl: Removing leading '/' from absolute path names
> > # file: usr/local/share/man/man3cw/urcw4.3cw
> > # owner: beebe
> > # group: wheel
> > user::rw-
> > group::rw-
> > mask::rwx
> > other::r--
>
> I'm glad you noticed that.  It is a bug.
> What's changed is that now Solaris includes the "mask:" field.
> Coreutils calls acl_get_file, then acl_entries
> to count the entries.  It used the heuristic that
> more than 3 entries indicates an ACL.
> Now there are always 4, even on files without an ACL.
>
> I hope there's an efficient way to implement has_acl, now.
> We'll see.
>
> I see that Solaris provides the acl_trivial function, with a
> const-incorrect prototype (it should be a "char const *" parameter).
>
> SYNOPSIS
>        cc [ flag... ] file... -lsec [ library... ]
>        #include <sys/acl.h>
>
>        int acl_trivial(char *path);
>
> DESCRIPTION
>        The  acl_trivial()  function  is used to determine whether a file
>        has a trivial ACL. Whether an ACL is trivial depends on the  type
>        of  the  ACL. A POSIX draft ACL is trivial if it has greater than
>        MIN_ACL_ENTRIES. An NFSv4/ZFS-style ACL is trivial if  it  either
>        has entries other than owner@, group@, and everyone@, has inheri-
>        tance flags set, or is not ordered in a manner that  meets  POSIX
>        access control requirements.
>
> But that won't help non-Solaris systems that mount a ZFS file system.
>
> My first reflex was to just use MIN_ACL_ENTRIES in place of "3"
> here, in lib/acl.c:
>
>             ret = (3 < acl_entries (acl));
>
> But it can't work.  On a non-Solaris system like abajo,
> the number to compare against is 3 on e.g., local ext3 file systems
> but 4 on remote-mounted ZFS file systems.
>
> > The other peculiar thing is that when I do a "make install"
> > to install the man pages from abajo, I get reports like this:
> >
> > cp: setting permissions for `/usr/local/man/cat3cw/ldexp.3cw': Invalid
> > argument
> >
> > This too seems to be new with coreutils-6.8.
>
> This is due to the same underlying problem.
> strace shows that the failing syscall is fsetxattr, with EINVAL.
> cp thinks there's an ACL and is trying to preserve it.

Here's a possible solution:

If the presence of the "mask:" entry is a reliable indicator
that MIN_ACL_ENTRIES is 4, then we could implement something
whereby for one file per distinct file system (st_dev value)
we'd examine ACL entries looking for a "mask:" one, and maintain
a table mapping st_dev value to the MIN_ACL_ENTRIES value for
that file system.

Call it pre-optimization, but somehow, I think performing all of
those ACL-related syscalls and string compares for each and every file
processed would be too much of a performance hit.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]