Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] User/Group Account Management Proposal

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: David Kowis <dkowis AT shlrm.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] User/Group Account Management Proposal
  • Date: Mon, 09 Jan 2006 15:11:06 -0600

Hello fellow Magers,

I've been thinking about how Source Mage handles users while debugging a problem on one of the latest test ISO's. (Which, if you've not been testing, you should be :) ) I've noticed that users are only automagically added. They're not tracked and automatically removed. In my own twisted little mind, if they're automatically added then they should be automatically removed when they're no longer in use. For example: I install postgresql, the user postgres is created, I didn't know that this user is created, but nonetheless it's there. After dispelling postgresql, because I decided that mysql is a better venue for the software I'm working on/with, the postgres user remains on the system. What I'm proposing is that the users get tracked somehow. If a spell needs the user it's added, upon compile or resurrect. If the spell has that user and it is dispelled, then the user should also vanish, unless, of course, it's being used by another spell.

Now, this brings up a few things to consider. First, the users being added would have to be stored in some stateful mechanism. That way the system can track which software is using which users.

Second problem that comes to mind, is if the user sees the, for example, www-data user and decides to use it for some other implementation. That could be a "Bad Thing" (C). So, in the user comment field in /etc/passwd, users added would contain "Volatile SMGL system user" or something similar to make it quite obvious that the aforementioned user may vanish from the system at any change of software.

Possible advantages: An easy way to ensure that the users for each piece of software exist and don't exist when they're no longer in use. Maintaining a minimal /etc/passwd and /etc/group even through the extended use of a computer.

Possible disadvantages: Means some sofwtare will have to be written to maintain this stateful information and track when changes are made. It's yet another thing to track.

Possible implementations: IMHO, (these are just my thoughts on the matter, the actual implementation can and probably will vary) a file called ACCOUNTS would be optimal. It would simply contain the user name that the software requires. Then on cast/dispel/resurrect the user would flow through it's existance and non existance quite easily. Another method is via functions in BUILD, PRE_RESURRECT "create_account foo" and in POST_DISPEL "clean_account foo" Obviously, to me anyway, it's more efficient, in the long term, to simply have an ACCOUNTS file that contains enough metadata to tell the underlying control system what accounts it uses.

I feel that if we're going to automatically add users, we should then assume responsibility for removing those users when the software that uses them no longer is installed. With the proper information to the user, it doesn't propose any greater risk. Source Mage is generally assumed as install-once software. You simply don't need to install it again. Since we don't track the users that are installed, other than simply checking for existance before attempting to create, it can easily lead to a "user bloat" in a long-standing system. I thought I'd throw my thoughts out onto the Mailing List and see what other people have to think about this as well.

Thanks, David Kowis

ISO Team Lead - www.sourcemage.org
SourceMage GNU/Linux

Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
- Robert Heinlein

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Attachment: pgpyGbe9c4UBO.pgp
Description: PGP Digital Signature




Archive powered by MHonArc 2.6.24.

Top of Page