On Thu, Apr 05, 2007 at 08:31:32PM -0400, Greg Troxel wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> 
> Your changes sound like excellent forward progress.

Yeah, I finally feel like I am beginning understand why the code is
doing certain things.

> Do I understand correctly that venus trying to recheck suspect rights
> may result in a 'yes' or 'no' from the server, and that 'no' will lead
> to denied local access, but failing to get an answer will be esesntially
> the same as not trying to check?

Correct, I have a change which should avoid unnecessary calls to the
server if we have suspect rights and the user is not authenticated. But
I'm not certain how effective that is because even if we don't refetch
a parent directory just because the rights are suspect, we may still end
up calling getattr because the directory itself is considered updated on
the server.

> There's a semi-separate issue which is whether to present
> unauthenticated data to a client at all.   I'd argue that only

I agree, that is why I wanted to get this part working first.

> authenticated replies from the server for acls or about new VVs should
> be accepted, so while there are no tokens no updates are obtained and
> it's like one is disconnected.

The client never sees ACLs, it presents an identity to the server in the
form of a Coda token and then whenever we get attributes of a directory
the server returns a bitmask of the permissions this identity has on the
directory and it's children. So the server is the only one that knows
about groups and acls.

But that is beside the point here, I'd say this is probably not that
hard, we already block reintegration for unauthenticated users. So we
really only have to avoid connecting for read operations. This can be
done by failing in userent::Connect for any unauthenticated connections.
The only problem is what errorcode we should return so that it is
handled correctly on the way out (and so that the error makes sense to
the end-user/application).

Maybe EPERM or EACCESS, there are also a bunch of other errno's that may
work but I'm not sure how if they are supported across different
platforms and how applications would respond if they get any of these
errors as a result of a file system syscall (open/close/stat). I
normally try to stick to errors defined in manpages or in the single
unix specification, but those typically don't include any of the
following,

    ENODATA ECOMM ECONNABORTED ENOTCONN ENAVAIL ECANCELED ENOKEY
    EKEYEXPIRED EKEYREVOKED EKEYREJECTED EOWNERDEAD

Jan