(Illustration by Gaich Muramatsu)
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. JanReceived on 2007-04-06 09:41:05