On Fri, 22 Feb 2002, Jan Harkes wrote:
> If an object is cached, but accessibility for this object by the
> requesting user is not, there is an RPC that does nothing but the access
> check. Every object has a small but fixed 'cache' of the access rights
> of the last 6 people that tried to access
On Fri, Feb 22, 2002 at 02:18:23PM +0100, Ivan Popov wrote:
> On Thu, 21 Feb 2002, Jan Harkes wrote:
> > So if local user 'billg' does a clog with my Coda-token in disconnected
> > mode, he still does not gain any access to my files because the objects
> > have only stored that they are accessible
On Thu, 21 Feb 2002, Jan Harkes wrote:
> So if local user 'billg' does a clog with my Coda-token in disconnected
> mode, he still does not gain any access to my files because the objects
> have only stored that they are accessible by the local user 'jaharkes'.
How is it with cached objects acces
On Thu, Feb 21, 2002 at 01:25:41PM +0100, Ivan Popov wrote:
> On Mon, 18 Feb 2002, Jan Harkes wrote:
>
> > The only way we could block non-root users from seeing the cache is by
> > encrypting the tokenfile with the user's password and some additional
> > randomness provided by venus. Then if we
On Thu, Feb 21, 2002 at 11:19:50AM -0500, Jan Harkes wrote:
> This actually shouldn't be possible, but only because venus really
> trusts 'kernel credentials' more than the 'token credentials'. But I
> would have to double check to see which 'user-id' is put in the access
> granted field of cached
On Mon, 18 Feb 2002, Jan Harkes wrote:
> The only way we could block non-root users from seeing the cache is by
> encrypting the tokenfile with the user's password and some additional
> randomness provided by venus. Then if we pass up the token and the
> password, venus can decide if it is a unch
On Mon, Feb 18, 2002 at 08:43:04AM +0100, Rene Rebe wrote:
> On: Mon, 18 Feb 2002 00:54:38 -0500, Jan Harkes <[EMAIL PROTECTED]> wrote:
> > On Mon, Feb 18, 2002 at 06:23:55AM +0100, Rene Rebe wrote:
> > > > As long as the client remains disconnected, it won't 'really' discard
> > > > the user's to
Rene Rebe <[EMAIL PROTECTED]> writes:
> This doesn't seem to be as user-firendly as the "weekend trip" stories
> in all the CODA paper suggest ;-)! - I'll take a look ...
Erm, just a suggestion...
I created my /local/home/tokenfile about a year ago,
and it also expired last year, but I still
use
On: Mon, 18 Feb 2002 00:54:38 -0500,
Jan Harkes <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 18, 2002 at 06:23:55AM +0100, Rene Rebe wrote:
> > > As long as the client remains disconnected, it won't 'really' discard
> > > the user's tokens so that you continue to have whatever access
> > > permiss
On Mon, Feb 18, 2002 at 06:23:55AM +0100, Rene Rebe wrote:
> > As long as the client remains disconnected, it won't 'really' discard
> > the user's tokens so that you continue to have whatever access
> > permissions were cached at the time of disconnection.
>
> This doesn't seem to be as user-fir
Hi.
On: Sun, 17 Feb 2002 23:56:51 -0500,
Jan Harkes <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 18, 2002 at 03:49:25AM +0100, Rene Rebe wrote:
> > 1. As written in the CFS Manual page 59 point 8 I can not get tokens
> > when the client is disconnected. How should I work with CODA when I'm
> > o
On Mon, Feb 18, 2002 at 03:49:25AM +0100, Rene Rebe wrote:
> 1. As written in the CFS Manual page 59 point 8 I can not get tokens
> when the client is disconnected. How should I work with CODA when I'm
> on a trip, in a train, car, plane, ... ?
As long as the client remains disconnected, it won't
12 matches
Mail list logo
