Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Am Wed, 27 Sep 2006 11:17:36 +0200
schrieb Flavien Bridault <vlaaad AT sourcemage.org>: 

> I have the possibility to propose a project for master students in my
> university (the first in France that propose a master in open-source
> software :-) ).
> 

Well, AFAIK we need a proper up-to-date hardened grimoire with grsecurity, 
pax,(or
SELinux) 'n stuff. Or perhaps better these security features properly
integrated into main grimoire.
Perhaps some work to help setting up a secure SGML server...

Also there is the account handling system that some of us (including me)
are interested in getting changed thouroughly.
This is quite a distinct project, main relation is perhaps with the
future stage root install, esp. in the question of INSTALL_ROOT != /
installs.
I may take this chance to publish the ideas Ruskie and me jotted down
about what this system should be able to do.
I sort of opted to do the main work and am still willing to do it but
cannot make promises about the _when_ since I have to finish my own
thesis.
So this may be a candidate:


          The Source Mage GNU/Linux System Account Management
          ===================================================


The basic function of the Source Mage (grimoire) account handling is to
give spells an interface for creation of accounts and managing
permissions for these accounts. It also is there to give the user
control over the accounts spells work with.

The starting point is a simple list of symbolic names and numeric IDs of
users and groups and some basic data fields for them. Accounts are
looked up in this list and created if needed so that spells can install
files for the specific user / group or configure init scripts for
starting daemons.

There are some more advanced features needed:

a) flexible uid/gid

Source Mage is not always in the position to enforce a fixed set of IDs.
there may be an existing environment with accounts and there may be the
user just having an own opinion about user/group IDs.

The grimoire should provide a default, consistent list of names and IDs
but the user should be able to override that by either setting single
fixed IDs or choosing ranges of possible system account IDs from that
spells will pick available ones.

Question is here how and where configuration will happen.


b) flexible symbolic names (names in spell really symbols for the
symbols)

The user should also be able to change the symbolic names of accounts.
Some want an ntp user, some want ntpd, some may want a nettime user.
We should separate the same spells use internally from the name that
actually is used after installation.


c) account adding optional 

User shold be able to decide on account management to happen. Spells
should accept denial by using fallback accounts (root, nobody).
Also, one can think of two modes of operation for user managed accounts:

  - spells asking/forcing user to create accounts, not continuing until
they exist
  - spells failing if account not precreated
  -> account_add -f in spell indicating that it _really_ needs the
account


d) better handle / detect existing accounts

Existing account really valid if symbolic name matches? ID ranges?
Description?


e) add more properties like home dir, description, secondary groups...

Every smgl system user needs proper description, as well as the
reasonable usual set of properties.


f) support multiple symbolic names for one uid (same for gid)

There are uses for different account behaviour (shell, home) with same
file access rights... One could decide to use only one numerical id for
a bunch of daemons. Though the configurable symbolic names would provide
another way to make different daemons use the same user, the uses from
the first sentence still apply.


g) On chroot casts do _not_ modify the host's account database but the
one on the system being installed.

That should be easy enough once we have stable stage root (just thinking
about /etc/passwd and /etc/group here). Though care has to be taken for
a future cross compile feature where the host is possibly not able to
run any installed programs in the chroot (like useradd) - but we are not
in cross compile world yet.


And now something more difficult:

g) system-dependent methods for account management

This includes thinking about how to work with accounts in general. We
could get away for most systems by just hacking around in /etc/passwd
without even using useradd/groupadd.
But there are various methods for storing user accounts... 
Also, we can handle advanced stuff (like chroot casting) easily by
simple hacking of passwd/group files explicitly without using any system
tools.

Thinking about this points is thinking about the basic operation, the
underlying actual function of the account handling system. But perhaps I
exaggerate.



Alrighty then,

Thomas.

Attachment: pgpJSOBOthIm5.pgp
Description: PGP signature