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

[James Youngman]

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

IFS=:
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
asked.


James.