[Top][All Lists]

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

Re: Problem with find + AFS + acl="l"

From: James Youngman
Subject: Re: Problem with find + AFS + acl="l"
Date: Wed, 1 Nov 2006 15:19:44 +0000

On 11/1/06, Daniel Richard G. <address@hidden> wrote:
On Wed, 2006 Nov 01 13:15:52 +0000, James Youngman wrote:
> IFF AFS has these properties:
> 1. "." and ".." are returned first
> 2. DT_DIR is returned for them
> ... then we could defer the lstat call until the point where we need
> information about the file.     I think that would meet your
> requirements.  But we should only do that if CONFIG_AFS was supplied
> AND we're sure the directory is an AFS directory (that is, we are sure
> that no entry for which DT_UNKNOWN is returned could ever be a
> directory).

Provided that the opendir() call is permitted, AFS always returns DT_DIR
for subdirectories, never DT_UNKNOWN---so recursion is not a problem.
(IIRC, AFS does have some potential for weirdness with "." and "..", but I
believe this was addressed by the -noleaf option.)

Perhaps I was unclear.  find needs to know how to handle the first
DT_UNKNOWN entry when it sees it.  (so does fts).  IFF AFS guarantees
that a DT_DIR entry will be seen before the first DT_UNKNOWN entry, we
could automatically turn on the behaviour you are talking about, as
long as we know the filesystem is AFS.

That aside, I don't think that the remaining DT_UNKNOWNs have to be handled
in an AFS-specific way. Wouldn't it be enough to have a switch that tells
find(1) not to examine these entries further?

No, Find may need to call lstat() to determine the answer to other
tests (-xtype, -type, -size for example).   The find program needs to
know if it should initially defer the lstat() on the grounds that it
has eliminated the possibility that a directory is a directory.
Doing this with a switch

0. Creates further user confusion; they have to understand and
remember to use yet another switch
1. Doesn't provide a speedup every time it is available, since most
users won't use the switch anyway
2. Offers extensive opportunities for long debugging/diagnosis
sessions where someone specified the switch when they shouldn't
3. Will probably unexpected results for scripts like this

find $PATH ! -perm +001

The DT_UNKNOWN behavior will
be consistent for any AFS path, and it is highly unlikely that you'll have
find(1) scanning /afs and some other filesystem (with potentially
different behavior) in the same invocation.

> How can we determine this?  Does AFS guarantee the properties I describe?

I don't think I could use as strong a word as "guarantee," but the
aforementioned is the standard behavior for directories with "l" access.
AFS isn't returning DT_UNKNOWN willy-nilly; its design is deliberately such
that if you have list permission on a directory, listing is _all_ you can
do. You can see an entry, and see whether or not it is a subdirectory (in
which you may or may not have access under a different ACL), but all other
information is denied---even the specific non-directory file type.

The priorities for find are security and correctness.  Performance is
a way lower priority.  So I am interested in Doing The Right Thing,
which is why I asked the questions I asked.  I have no access to AFS
so that's why I needed you to help me by answering the questions I


reply via email to

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