From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3643bbeabcff786c34b15f06876f75d2@plan9.bell-labs.com> From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] removing users In-Reply-To: <20030619182445.GA6452@thefrayedknot.armory.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 19 Jun 2003 14:48:59 -0400 Topicbox-Message-UUID: d0a83b68-eacb-11e9-9e20-41e7f4b1d025 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.