[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
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.
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/01
- Re: Problem with find + AFS + acl="l",
James Youngman <=
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/01
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/01
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/01
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/02
- Re: Problem with find + AFS + acl="l", James Youngman, 2006/11/03
- Re: Problem with find + AFS + acl="l", Daniel Richard G., 2006/11/03