Re: automatic adduser/addgroup in postinst (was Re: fingerd)
(Many things removed from the CC; debian-devel only now.)
Craig Sanders writes ("automatic adduser/addgroup in postinst (was Re:
fingerd)"):
...
> Maybe what we need instead of /etc/passwd and /etc/group in the base
> package is a program for use by postinst scripts which automatically
> creates new accounts and groups if they don't already exist.
Yes.
> Lets say, for example, that the scripts are called /sbin/adduser.debian
> and /sbin/addgroup.debian.
>
> The base package would contain the files "passwd.db" and "group.db" (in
> standard /etc/passwd and /etc/group file format) INSTEAD of /etc/passwd
> and /etc/group. These database would contain all standard debian user
> accounts and groups.
>
> The postinst for base would loop through these database files, creating
> new users & groups as required.
Right.
> adduser.debian is called once for each line in these databases.
>
> - if the username already exists, then nothing else is done (or perhaps
> a check to maked sure that uid & gid match...warn if they're different)
>
> - if the username doesn't exist, then it is created. The specified uid is
> just the preferred uid. If it is already in use, then another uid
> is randomly (?) selected. This needs some very careful thought to get it
> right. Maybe there should be a range of reserved uids which should
> only be allocated by the base package maintainer (BPM)?
No, it should be an error for the preferred uid to be in use, at least
for uids allocated in the 0-99 range.
> If so, this should be documented!
> Perhaps uids 0-499 & 65535 should be allocated by the BPM, and uids
> 500-999 are available for debian developers to use and experiment
> with until they get an official uid allocated by the BPM. uids >=1000
> and < 65535 are available for user accounts.
Currently 0-99 and 65534 are allocated statically by the base system
maintainer, 100-999 are allocated dynamically by adduser for system
users and groups and 1000 onwards for ordinary users.
I think that the functionality of updating the password and group
files appropriately should be in adduser.
...
> anyone know if diff is versatile enough to do what's needed here? or
> should we write a sh/sed/perl/awk/whatever script to do it? it
> wouldn't be very difficult program to write, but there's no sense in
> reinventing the wheel if an existing tool can do the job.
diff can't do it, and in any case you need to do lots of locking.
I think the single tool to do the job should be adduser (which doubles
as addgroup at the moment, and should probably continue to do so).
> addgroup.debian would do somthing similar for the /etc/group file.
The two really ought to be one program, especially considering our
default `users have their own groups' arrangement.
> If this is done and documented, then developers of new packages that
> require a special uid or gid can:
>
> 1. apply to the BPM for a uid, who allocates one and adds it to the
> database mentioned above... The BPM then emails the developer
> informing him/her of the allocated uid or gid.
>
> Ditto for gids.
>
> 2. modify any ownerships, groups, etc of their package and package
> source if required.
>
> 3. modify or create their package's postinst script to call
> adduser.debian or addgroup.debian as required.
>
> This way, when a user installs the package if the uid or gid doesn't
> exist, then their system is seamlessly updated. If they do already
> exist then no damage is done.
>
> 4. edit /etc/passwd and /etc/group on their own system to bring it into
> line with the debian standard.
>
> also, execute "find / -uid <olduid> | xargs chown <newuid>" to make sure
> everything is owned correctly. And a similar "find ..." for gid as well.
Except that we don't want <olduid> != <newuid>, yes.
Ian.
Reply to: