patch: makes adduser.conf a symlink to a profile (provides switchable profile feature to all frontends)

Bug #489136 reported by ceg
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
adduser (Ubuntu)
Triaged
Wishlist
Unassigned

Bug Description

Binary package hint: adduser

Default profiles could be shiped for admininstrator, desktop and unprivileged users.

Currently different frontends have implement and configure user profiles differently, easily leading to inconsistencies when users are created with different tools. Even if they use adduser to create users, they have override much, somtimes even IDs.

Simply by making /etc/adduser.conf a symlink and maybe package two or three default profiles all tools would have a way to share and choose between the same profiles and would use the same defaults.

Revision history for this message
ceg (ceg) wrote :

In order to mimic the user profiles currently shiped with gnome-system-tools:

 * mv /etc/adduser.conf /etc/adduser.conf.unprivileged

 * create adduser.conf.desktop
  - with EXTRA_GROUPS="cdrom floppy dialout tape dip adm plugdev fax audio scanner fuse video"
  - andADD_EXTRA_GROUPS=1

 * create adduser.conf.administrator
  - with EXTRA_GROUPS="cdrom floppy dialout tape dip adm plugdev fax audio scanner fuse admin sambashare lpadmin video"
  - and ADD_EXTRA_GROUPS=1

 * ln -s /etc/adduser.conf.desktop /etc/adduser.conf

Revision history for this message
ceg (ceg) wrote :

This is my first try at using bzr.

I created an own branch from the lucid brach, changed what I could while browsing through the files, committed and used send -o to produce the attatched file. Was that correct?

Any recomendations welcome.

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

Indeed, that would be very nice. But we also need support for that in the system-tools-backends, and in the gnome-system-tools, which would require detecting whether the distribution supports this, and fall back to the custom handling of profiles if it doesn't. But we should discuss that on bug 488913.

Changed in adduser (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
summary: - make adduser.conf a symlink to adduser.conf.<profile>
+ Ship adduser with user profiles to unify their handling by different
+ tools
ceg (ceg)
summary: - Ship adduser with user profiles to unify their handling by different
- tools
+ Ship adduser.conf as symlink to user profiles to unify their handling by
+ different tools
description: updated
ceg (ceg)
summary: - Ship adduser.conf as symlink to user profiles to unify their handling by
- different tools
+ Ship adduser.conf as symlink to a profile (provides switchable profile
+ feature for all frontends)
summary: - Ship adduser.conf as symlink to a profile (provides switchable profile
- feature for all frontends)
+ patch: makes adduser.conf a symlink to a profile (provides switchable
+ profile feature to all frontends)
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

The main issue now that users-admin uses adduser for most settings is that we'd need to move all profile handling logic to the backends, and then rely on the platform's tools (here adduser) if possible. There need to be a fallback since not all platforms (will) support this feature.

For sure, that won't happen this cycle. It would be good to think more about this to see what other improvements we can bring by moving to this new behavior, so that we don't redesign the protocol at every version.

Another concern is that the Unprivileged profile doesn't really work ATM, since most system groups we show aren't used anymore. So this account type is basically as powerful as a standard Desktop user (see bug 326135).

Revision history for this message
ceg (ceg) wrote :

If policykit broke the desktop and unprivileged profiles this is a bug with policykit not being set up to honor those unix groups.

I don't see user profiles only with respect to g-s-t. It seems usefull also for admins not using g-s-t. As adduser is supposed to be thesystem wide tool, even the installer creating users during install should benefit from it.

Regarding gst-backend features:

* make the frontends fetch defined defaults (and profiles) through the backend
* if adduser is used, backend parses /etc/adduser.conf for active system defaults
* check if it is a symlink
* parse other available adduser.conf.profiles
* option to choose between those profiles (--conf FILE)
* option to switch default system profile (symlink)
* if adduser is not used backend parses /etc/g-s-t/ for defaults and available profiles

Revision history for this message
ceg (ceg) wrote :

Could you consider the adduser patch for building packages that can be tested/used (independently from g-s-t)?

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

Other bug subscribers

Remote bug watches

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