Ubuntu
gnome-system-tools package

users-admin profiles default to force [GU]ID, home dir, shell and groups to adduser

Bug #488913 reported by ceg
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-system-tools (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Binary package hint: gnome-system-tools

splitting this from #488158

> We implement user profiles in users-admin. Those allow the distribution/admin
> to present users with typical account types, which set sensible default values
> for home dir, shell, groups membership (esp. admin)

Nothing wrong with those, because adduser is used and say EXTRA_GROUPS defined in /etc/adduser.conf will be honored, right.

> and UID.

With this however I believe that any tool should *default to* leave the assignment of numerical IDs to be the responsibility of the system (it's part of the stuff that gets tweaked centrally in /etc/login.defs and /etc/adduser.conf)

>It's kind of silly we implement [user profiles] on the GUI side, but as we can't
> be sure the distribution supports this kind of feature (and none does ATM)

Its probably ok if profiles are not supported otherwise and its easier then submitting a patch.

>All I can do for now is have a look at the profiles handling code so that when
> no profiles are set, we don't specify any UID, and the backends leave adduser
> decide for us. Not very hard, but our protocol does not support it ATM.

Great. And its probably all that would be needed. Together with removing the settings that override system defaults from the shipped profiles. (i.e. have empty uid-min=, uid-max=, home-prefix= and shell= lines ; since those should have sensible system defaults)

(OT: Of course a patch to useradd -D or adduser to support different profiles would still be great, too. Single profile definition and configuration code is available in adduser.local. The doc is on any debian/ubuntu system file:///usr/share/doc/adduser/examples/README )

See original description
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Maybe I should precise that [GU]ID ranges set in /etc/adduser.conf are still honored, it's only that users-admin chooses the ID itself in that range. So no real problem in that regard. We should just allow profiles not to be used if wanted.

(About "services" form adduser.local.conf, they don't seem to fit our needs because they are not considered as alternative account types, and don't include the settings we need. See file://etc/gnome-system-tools/users/profiles.)

Changed in gnome-system-tools (Ubuntu):
importance: Undecided → Low
status: New → Triaged
description: updated
summary: - users-admin defaults to override system wide defaults from
- /etc/login.defs, /adduser.conf
+ users-admin's profiles feature forces [GU]ID, home dir, shell and groups
+ to adduser
Revision history for this message
ceg (ceg) wrote : Re: users-admin's profiles feature forces [GU]ID, home dir, shell and groups to adduser

Even better then. :)

(yes adduser.conf and adduser.local.conf together provide only "one profile" )

summary: - users-admin's profiles feature forces [GU]ID, home dir, shell and groups
+ users-admin profiles default to force [GU]ID, home dir, shell and groups
to adduser
Revision history for this message
ceg (ceg) wrote :

Oh, I just realized that adduser supports user profiles, maybe even since its first version.

System wide profiles can be provided as adduser.conf.<profile> and the profile is selected with:
# adduser --conf adduser.conf.<profile> <username>

Revision history for this message
ceg (ceg) wrote :

Alternativly adduser.conf can be shipped as a symlink to a adduser.conf.dist (distribution) profile.

This allows to switch the symlink to an admin provided profile, so that it will be used as a adduser default, without having to touch the .dist profile.

Revision history for this message
ceg (ceg) wrote :

I have actually produced a patch to adduser now, as far as I could. Since it is my first one I'd appreciate any feedback. Its in LP: #489136

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Do you think you could try to implement the support for adduser profiles in the system-tools-backends? I'm currently reworking the D-Bus protocol, so it would be the time to make these changes if we want. They are written in perl.

Revision history for this message
ceg (ceg) wrote :

I have had a look into /usr/share/system-tools-backends-2.0/scripts/Users/Users.pm. Unfortunatly I am not at all familliar with perl.

If it is currently reading in settings from /etc/adduser.conf it should work with a linked profile as well, what you mean is probably reading in other installed profiles as well, and providing those to the frontend to choose from. I have to regret, I do no see how to do that.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Yeah, that's not completely trivial, that's why I don't say you: "OK, I'll fix that in two hours for the next release". I'm not sure I'll have the time to try implementing this for Lucid.

perl is not very hard to understand when you have priori knowledge of C or another similar language. You'd need to list the files that correspond to a given pattern to find out what profiles are available, and then change the D-Bus protocol in ./UsersConfig.pl to send that information and get it back. I must admit that's not completely easy...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.