users and user accounts

[Kurt Cockrum]

Maybe it's time for some CPSR person to lend some technical expertise to
the problem of dealing with the life-cycles of user and account instances,
to borrow some OO (object-oriented) jargon.  I think that might be a way of
making the problem more tractable.

It might be useful to consider that part of this is a namespace management problem
similar to those that the various interNICs have to deal with, namely, the life-cycle
of a domain name, issues of reuse and side-effects of previous incarnations, dormancy,
etc.

Various questions need to be asked:
o	What happens to accounts when users die?
o	What happens to accounts when users disappear (not die)?
o	what happens to accounts when users go to jail, or users get out of jail,
	or join the armed services, or get out of the armed services,
	or move to another country, or change their name, or change their account name,
	or change their address, or change their password, or forget their
	password, or change their telephone authentication Q-and-A,
	or change their sex, or decide to start
	writing their handwritten signature in a new way, or never log in,
	or <zillions of other humanly significant transitions which ripple-over to our
	 particular framework>...
	Many of these can be folded into a single situation, of course.  They do need
	the scrutiny, though.  Bear in mind that all of these changes can revert to their
	previous state, and can do this more than once, in an arbitrarily cyclic fashion.
o	What's the relation(s) between users and accounts?  Can we have users without
	accounts? accounts without users?
o	What's the relation between users and real live human beings (MeatObjects(TM))?
	Not all users are coupled to a MeatObject, for example the "ftp" or "bin"
	users.  In the case of the "root" user instance, multiple MeatObjects are coupled
	to it (all the MO's who know the root password).  For ordinary SCN users, we want
	each one to be coupled to a MeatObject.
o	What objects are the custodians of various attributes or other objects?
	For example, to what does a "password" belong to?  It would appear that this
	is an attribute of an account instance, but at least one MeatObject knows
	it (but there are cases where that might not be true, as when the last MeatObject
	sharing an account forgets the password).
o	Can we cope with Y2K problems?  What about users who attempt to log in
	on Jan 2, 2001, after having previously logged in some time in 1999?
o	Note that I have elided the distinctions between users and MeatObjects in
	several of the above cases.

Both the user and account objects/classes need to have the various states and transitions
of their respective lifecycles defined, in essence.  Analysis and design work is needed.
The concept of "framework" might be useful here; maybe somebody else has already
done the work.  The particular "framework" might be one appropriate to a freenet ISP.

In the current instance, where about 7K accounts just suddenly underwent the transition
from "active" to "dormant" states (both states urgently needing definition) one hopes
they weren't simply thrown away without further thought.  It certainly ought to be
possible to recover an account.  Presumably this includes the password, home
directory tree, mailbox, last login information, whatever else is relevant.  Just
how long this ought to be possible is an attribute of the life-cycle.

I think it would be extremely imprudent to recycle usernames (at least the
automatically generated ones), without giving due thought to possible consequences
and whether we can or want to cope with them.  Vanity ID's could be recycled, but
the caveats ought to be explained.  For example, what if a previous MeatObject
belonging to a vanity ID (a kind of user) was a spammer?  The current MeatObject
with the recycled vanity ID won't appreciate receiving hate mail directed to the
previous MeatObject.

Hopefully more knowledgable folks, actually doing OO stuff, will comment.  I'm just
an amateur here.
--kurt
 I've always thought rock-and-roll made sex and drugs a whole lot less fun than
 they could've been.  Or maybe it's that sex and drugs made rock-and-roll tolerable.
* * * * * * * * * * * * * *  From the Listowner  * * * * * * * * * * * *
.	To unsubscribe from this list, send a message to:
majordomo at scn.org		In the body of the message, type:
unsubscribe scn
END