[9fans] removing users

[9fans] removing users

[Andrew]

how does one remove a user from a fossil file server? do you edit the
users file by hand have fossil re-read it and then delete their files? or
is there a different way?

thanks

Re: [9fans] removing users

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 53 bytes --]

I edit the file by hand. There may be a better way.

[-- Attachment #2: Type: message/rfc822, Size: 1438 bytes --]

From: Andrew <afrayedknot@thefrayedknot.armory.com>
To: 9fans@cse.psu.edu
Subject: [9fans] removing users
Date: Wed, 18 Jun 2003 16:06:26 -0700
Message-ID: <20030618230626.GA32362@thefrayedknot.armory.com>

how does one remove a user from a fossil file server? do you edit the
users file by hand have fossil re-read it and then delete their files? or
is there a different way?

thanks

Re: [9fans] removing users

[Russ Cox]

If you're running dumps, it's not a good idea to remove
users -- their ids will still be found looking in the dump.

You can rename the uname with 'uname old %new' but
you shouldn't get rid of the uid.

Russ

Re: [9fans] removing users

[Andrew]

so i should rename them all to some null user which is unable to log in?

On Thu, Jun 19, 2003 at 01:50:53PM -0400, Russ Cox wrote:
> If you're running dumps, it's not a good idea to remove
> users -- their ids will still be found looking in the dump.
>
> You can rename the uname with 'uname old %new' but
> you shouldn't get rid of the uid.
>
> Russ
>

Re: [9fans] removing users

[boyd, rounin]

> so i should rename them all to some null user which is unable to log in?

removing users is always a bad idea.  once you blow them away you have
lost the trace of who they were, what they did and what they might be doing.

they should always be retired;  turn off their access but leave their
'existance' alone.

Re: [9fans] removing users

[Russ Cox]

> so i should rename them all to some null user which is unable to log in?

Don't rename them all to the same thing.
That will just confuse you later.  We don't
ever remove people -- we just turn off their
accounts on the auth server.

We had a spell where we renamed foo to usedtobefoo,
but we've basically given up on that too.

Russ

Re: [9fans] removing users

[Andrew]

On Thu, Jun 19, 2003 at 02:39:28PM -0400, Russ Cox wrote:
> > so i should rename them all to some null user which is unable to log in?
>
> Don't rename them all to the same thing.
> That will just confuse you later.  We don't
> ever remove people -- we just turn off their
> accounts on the auth server.
>
> We had a spell where we renamed foo to usedtobefoo,
> but we've basically given up on that too.
>
> Russ
>

is it okay to remove their files from the active filesystem (since venti
has them already) or is that unnecessary?

thanks for all the help.

Andrew

Re: [9fans] removing users

[Russ Cox]

> is it okay to remove their files from the active filesystem (since venti
> has them already) or is that unnecessary?

sure, but it won't free up any disk space.

Re: [9fans] removing users

[Andrew]

On Thu, Jun 19, 2003 at 02:51:12PM -0400, Russ Cox wrote:
> > is it okay to remove their files from the active filesystem (since venti
> > has them already) or is that unnecessary?
>
> sure, but it won't free up any disk space.
>
i know it wont get removed from venti, but will it clear off any space
from the fossil drive?

Re: [9fans] removing users

[Russ Cox]

> i know it wont get removed from venti, but will it clear off any space
> from the fossil drive?

no -- it's not taking up any space on the fossil drive once it goes to venti.

Re: [9fans] removing users

[jmk]

On Thu Jun 19 14:25:21 EDT 2003, afrayedknot@thefrayedknot.armory.com wrote:
> so i should rename them all to some null user which is unable to log in?
>
> On Thu, Jun 19, 2003 at 01:50:53PM -0400, Russ Cox wrote:
> > If you're running dumps, it's not a good idea to remove
> > users -- their ids will still be found looking in the dump.
> >
> > You can rename the uname with 'uname old %new' but
> > you shouldn't get rid of the uid.
> >
> > Russ

the format of users file is:

	id:name:[leader]:[members[,members]]

	id is what is used to store in the file system
	name is what the outside world (9p) sees and deals with
	leader is the group leader (may be nil)
	members is a comma-separated list of who is in the group

a check is made when the users file is read by the server that
there is only one id<->name mapping.

so, say we have
	bob:bob::
and create some files. these files are on permanent storage in the
back end (venti, the original standalone fs, whatever) and the id 'bob'
is tied to those files irrevocably.

if bob leaves, we just need to turn off his ability to authenticate
to the server, there's no real need to remove his files and, in fact, those
files of his in the dump cannot be changed or removed.

the idea is that if a new bob arrives we can still give him the name bob
by changing the old bob entry to
	bob:bobwholeft::
(this is accomplished by using the 'uname' command in fossilcons(8), e.g.
	uname bob %bobwholeft
)
and then making a new entry
	newbob:bob::
via
	uname bob newbob

but there no way the new bob can access the old bob's files as they
are stored under different ids.

Re: [9fans] removing users

[Scott Schwartz]

> so i should rename them all to some null user which is unable to log in?

If that's the issue, there should simply be a bit in some file that
says "not allowed to log in".  That's much better than overloading
other fields.

Re: [9fans] removing users

[Russ Cox]

> If that's the issue, there should simply be a bit in some file that
> says "not allowed to log in".  That's much better than overloading
> other fields.

There is.  On the authentication server.

Re: [9fans] removing users

[boyd, rounin]

> If that's the issue, there should simply be a bit in some file that
> says "not allowed to log in".

no, the auth server/protocol should be sufficiently flexible to
invalidate their auth credentials and that should do it.

Re: [9fans] removing users

[boyd, rounin]

> no, the auth server/protocol should be sufficiently flexible to
> invalidate their auth credentials and that should do it.

having said that, i have commited the crime of overloading 'in-band' data.

russ' later post is what i should have said.