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

[Daniel Richard G.]

On Wed, 2006 Nov 01 13:15:52 +0000, James Youngman wrote:
> On 10/28/06, Daniel Richard G. <address@hidden> wrote:
> >I am using find(1) at an AFS site to produce file lists for indexing.
> 
> Unfortunately you don't indicate which version.  It would be very
> useful if you did.

This was 4.2.27, sorry. I didn't see any discussion of this issue on the 
list, so assumed that CVS would be no different.

> find uses lstat to determine if it shoud recurse into that entry.   It
> assumes that entries for which DT_UNKNOWN was returned might be
> directories (since readdir didn't seem to know).

I noticed that. With AFS, the assumption doesn't appear to hold.

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

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

> How do the results differ if you use the ftsfind in findutils 4.3.x?

I'll give it a try, but am presuming that fts_read() et al. won't fare any 
better than readdir().


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = address@hidden        ##  don't smell bad---    (/o|o\) /
EMAIL2 = address@hidden      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)