On Fri, Apr 06, 2007 at 11:18:36AM +0200, u+codalist-p4pg_at_chalmers.se wrote:
> On Thu, Apr 05, 2007 at 11:07:14PM -0400, Jan Harkes wrote:
> > 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
> 
> It is hardly possible to choose a value good for all possible
> platforms and applications. Applications will be also presumably
> drifting towards more awareness of temporary/non-fatal error conditions.
> To help them distinguish such situations more error values would be desired
> (may the standards follow) - but as the last resort we have ETIMEDOUT.
> As misleading as it is, it indicates something non-fatal/retryable,
> potentially correctable.
> 
> On the practical side, I guess EPERM/EACCESS are pretty much "good enough".
> 
> Seeing "Connection timed out" is also ok with me, especially given
> an independent indication of availability of the servers (like "cfs cs"
> or vcodacon or something) so that the user realizes there is another problem
> than a network or server failure.

That's two votes for connection timed out, I'll think I can make that
work. Just have to skip the part where we reset and disconnect existing
connections for authenticated users.

Not allowing unauthenticated connections is a bit more involved than I
first thought. The problem is that operations like 'cfs cs' and the
initial binding to a realm or volume will use an authenticated
connection if available, but if we haven't yet connected to a realm
there are no existing connections.

It is interesting, I think several types of administrative operations
like server probes (cfs cs) don't really care about authentication. But
resolving a realm root and mounting a volume should be treated like
GetAttr, they should operate on behalf of a specific (authenticated)
user.

Jan