On Sat, Feb 23, 2002 at 11:48:52AM -0500, Greg Troxel wrote:
> I think it is a good idea to step back and look at requirements:

Good points!

>   But probably sftp transfers in process should be aborted when doing
>   cunlog.  I try to do that when venus hoards a huge file at an
>   inconvenient time to tie up the modem for an hour and end up having
>   to kill/restart venus and not clog until I can spare the capacity.

Aborting ongoing operations is hard. In fact even ^C on an active
operation does send a special upcall, but we don't really know how to
handle this in venus, so it is for the most part ignored.

It pretty much involves finding which thread we intend to abort, which
is probably already pretty hard to do. And then forcing that thread to
abort whatever it is doing and release all the locks/allocation it had
obtained.

Alternatively, if SFTP had better flow control, it could be tuned to be
less agressive compared to concurrent TCP connections. In which case the
hoarding would become more of a background fetch, simply eating those
bits of bandwidth that TCP isn't using. It would still affect TCP a bit,
as we want to be able to ramp up as soon as the other connections end.

>   On my notebook, for files my uid got from the server, there is no
>   reason for venus to not let me read/write them, even if I have not
>   clog'd in a month and venus got a chance to talk to the server.
>   The only exception is if I have explicitly requested that the files
>   be unavailable.  And if want that, I probably want to zeroize the
>   cache, too.

An explicit cunlog is should clearly be a more powerful operation
compared to token expiry as far as u-uid/c-uid bindings are concerned.
An additional flag to flush all cached objects that are currently only
accessible by the user that called cunlog would be a nice addition.

> With that in mind, I'll assert
> 
>   A token represents the right to read/write files _from a server_ for
>   a defined period of time.  This is fine, and if one assumes that
>   server access and the ability to get tokens go together, this is a
>   reasonable situation.  Note that this means servers which might be
>   traveling with users then need to be authentication servers too.

Agreed

>   Access control at the user/venus boundary is really a separate
>   issue.  Venus could record the unix uid/coda user mapping from
>   getting tokens, and allow access based upon the uid for items in the
>   cache.  If the acls are cached with the directory, then these
>   decisions can be made.

We don't cache acl's on a directory. Just thinking out loud here, we're
caching access permissions on the fso's, actually access is defined by
the directory acl, so we're almost too flexible right now.

It might be possible to treat directories and files differently in
venus, so we wouldn't cache access for individual files anymore, but
only in the directories. This would have several advantages,
 - reduce the RVM memory footprint a bit as there are typically more
   files than directories.
 - we can make the per-directory access caches bigger, so it is less
   likely that our access entry is dropped on a multiuser system.
 - already know we can access siblings of a file, even when another user
   happens to have pulled it into the cache.
 - fewer objects to revalidate/purge when we're getting a new token, or
   lost a token (cunlog/expiry).

>   Merely reconnecting temporarily should not start requiring tokens.
>   If I plug my notebook in for a minute to do something else and venus
>   talks to a server, but I'm not paying attention, and then I go off
>   somewhere and try to get at my files and find that my privileges
>   have expired because of this, I'm going to be grumpy.

Agreed. It's pretty much the same deal with temporary connections and
hoarding. We throw away the stale entry before we start fetching the new
one. When we disconnect during the fetch we suddenly have access to
neither. I believe a getattr can be enough to lose the old data. There
seems to be no way to detect the difference between stale data and stale
metadata so we have the following 'fso states'
	\   data
metadata \  none  stale  fresh
---------+--------------------
none	 |   Y      N      N
stale    |   Y      Y      N
fresh	 |   Y      N      Y

When there is no metadata there is no Fso, so we definitely cannot have
data. When the metadata is stale, the data could be fresh, but the
callbacks don't carry that kind of information and we would revalidate
the metadata before the data anyways. The obviously missing state that
should be possible is the fresh/stale state.

>   An explicit cunlog could remove the unix/coda uid binding.  Thus _if
>   one trusts venus_, this can prevent others on a system from getting
>   at your files by getting your uid.  But this is kind of silly, since
>   then they can probably read the venus cache directly.

Only if they have 'root', but if they can get your uid they probably can
become root too.

> In summary, I think I'm arguing for an indefinite-life binding between
> uuid and cuid for files already in the venus cache - one that survives
> restarting venus.  This is security-wise analogous to copying files
> from /coda into a regular UFS filesystem, where one doesn't need
> authentication to read ones own files (or rather, that's what login is
> about, and having a uid is the equivalent of a token).

That might be as simple as removing the IsValidToken tests in various
places.

Jan