Skip to content

Support specifying (extra) groups for user in identity section#2265

Open
ogayot wants to merge 3 commits intocanonical:mainfrom
ogayot:extra-groups
Open

Support specifying (extra) groups for user in identity section#2265
ogayot wants to merge 3 commits intocanonical:mainfrom
ogayot:extra-groups

Conversation

@ogayot
Copy link
Member

@ogayot ogayot commented Nov 5, 2025

In the identity section, one can now specify the groups directive. The groups directive can be used to either:

  • get the user added to extra groups, in addition to the hardcoded ones (i.e., sudo, admin)
  • get the user added to the groups configured, ignoring hardcoded ones.

To discard the defaults:

  # Two equivalent syntaxes for specifying the list of groups
  groups: [sudo, admin, lpadmin]
  groups: {override: [sudo, admin, lpadmin]}

For supplementary groups:

  # Add the user to the wireshark group in addition to the default
  groups: {append: [wireshark]}

@ogayot ogayot changed the title Support speicifying (extra) groups for user in identity section Support specifying (extra) groups for user in identity section Nov 5, 2025
@ogayot ogayot force-pushed the extra-groups branch 3 times, most recently from 6f8cfbb to 34fdebe Compare November 5, 2025 10:12
@ogayot ogayot requested a review from dbungert November 5, 2025 14:06
Copy link
Contributor

@Chris-Peterson444 Chris-Peterson444 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick first pass

@@ -72,13 +83,8 @@ def __init__(self, app):

def load_autoinstall_data(self, data):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: the documentation states that append and override are mutually exclusive, I think we should assert that here with an AutoinstallValidationError here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I couldn't find a clean way to do that with the JSON schema so I did it manually in Python.

Copy link
Contributor

@Chris-Peterson444 Chris-Peterson444 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Full review this time. A couple of comments but otherwise looks pretty good to me, thanks Olivier.

raise ValueError
return cls(
username=data["username"],
realname=data.get("realname", ""),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: if we don't pass a realname in the identity flow then it will take the value of the user name. Here we set it to empty. Is the behavior difference intentional?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see this is the original behavior, but maybe more clear now they are closer together. I'll leave the question up so we can consider it but not blocking imo.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this realistically needs to be fixed in a follow on PR! Thanks for pointing it out!

Comment on lines -125 to +133
self.model.add_user(data)
self.model.user = User.from_identity_data(data)
self.model.hostname = data.hostname
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: why not use add_user here? I see we have a new implementation of add_user that does exactly this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I'd like to deprecate add_user.

First, because it doesn't "add" a user but configures the user (there can only be one).
Second because we're passing it the hostname, which has nothing to do with the user.

Copy link
Member

@dbungert dbungert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is sensible, thanks for this. Please rebase before merge. Sorry for the delayed review!

@ogayot
Copy link
Member Author

ogayot commented Feb 25, 2026

Will rebase. We discussed with Chris and we think we should clarify that useradd would still create a group named after the user in any scenario (unless we pass the --no-user-group option but we don't)

@ogayot ogayot force-pushed the extra-groups branch 2 times, most recently from 5444128 to b77d022 Compare February 26, 2026 19:21
@ogayot
Copy link
Member Author

ogayot commented Mar 3, 2026

ogayot added 3 commits March 3, 2026 14:09
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
In the identity section, one can now specify the groups directive.

By default, the user is added to:
 * the sudo group (hardcoded in Subiquity)
 * the admin group (hardcoded in Subiquity)
 * a group named after the user (automatically created by useradd(8))

The groups directive can be used to either:

 * get the user added to a list of supplementary groups,
 * get the user added to a list of groups, ignoring groups that are
   hardcoded in Subiquity.

To ignore hardcoded groups, use:

  # Two equivalent syntaxes for specifying the list of groups the user should
  # belong to:
  groups: [sudo, admin, lpadmin]
  groups: {override: [sudo, admin, lpadmin]}

And for supplementary groups:

  # Add the user to the wireshark group in addition to the default
  groups: {append: [wireshark]}

Note that in any case, the user will be added to a group named after them.
This group is automatically created by useradd.

Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants