Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

many: add _daemon_ as valid system username #13052

Merged
merged 5 commits into from
Aug 15, 2023

Conversation

mvo5
Copy link
Contributor

@mvo5 mvo5 commented Aug 1, 2023

With the recent adoption of the _daemon_ user in the spec RK011 by the rocks team we should follow suite and also support the new _daemon_ user for snaps.

This commit implements this support.

We also need to update the documentation once this is in stable and deprecate snap_daemon in favor of _daemon_

@mvo5 mvo5 added the Needs Samuele review Needs a review from Samuele before it can land label Aug 1, 2023
@codecov-commenter
Copy link

codecov-commenter commented Aug 1, 2023

Codecov Report

Merging #13052 (4e0207a) into master (22e1eb3) will increase coverage by 0.00%.
Report is 9 commits behind head on master.
The diff coverage is 100.00%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@           Coverage Diff            @@
##           master   #13052    +/-   ##
========================================
  Coverage   78.69%   78.70%            
========================================
  Files        1001     1002     +1     
  Lines      124324   124426   +102     
========================================
+ Hits        97839    97925    +86     
- Misses      20331    20343    +12     
- Partials     6154     6158     +4     
Flag Coverage Δ
unittests 78.70% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed Coverage Δ
cmd/snap-seccomp/main.go 63.38% <100.00%> (ø)
osutil/user.go 84.61% <100.00%> (ø)
snap/validate.go 95.24% <100.00%> (ø)

... and 8 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@pedronis pedronis self-requested a review August 2, 2023 08:25
Copy link
Collaborator

@pedronis pedronis left a comment

Choose a reason for hiding this comment

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

looking good, some comments

@@ -62,6 +62,11 @@ type AddUserOptions struct {
// allows as valid usernames
var IsValidUsername = regexp.MustCompile(`^[a-z0-9][-a-z0-9+._]*$`).MatchString
Copy link
Collaborator

Choose a reason for hiding this comment

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

do we still have use cases for this? do we need to expand its comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right now the thinking is that:
a) IsValidUsername is used to validate the name from osutil.AddUser() which is called by devicestate when adding users from the system-user assertion. Making this slightly more restrictive seems to be good to avoid that those names clash with the "system-usernames" from snap.yaml
b) IsValidSystemUsername is used to validate users from the "system-usernames" snap.yaml via "EnsureUserGroup". It needs to be always a superset of IsValudUsername because e.g. snap-seccomp will use it right now to validate users.

This all points to a problem with terminology though, we have a "system-user" assertion and a "system-usernames" piece in the snap.yaml. I was thinking to rename them to "IsValidAssertionUsername" and "IsValidSystemUsername" maybe? Or "IsValidAddUsername" and "IsValidEnsureUsername" (but the later feels weird).

Copy link
Collaborator

Choose a reason for hiding this comment

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

May leave the first alone and rename IsValidSystemUsername ro IsValidSnapSystemUsername. I think the doc comments of AddUser and EnsureUserGroup should also be updated to clarify their validation rules.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the great suggestion, I did this now.

snap/system_usernames.go Show resolved Hide resolved
With the recent adoption of the `_daemon_` user in the spec RK011
by the rocks team we should follow suite and also support the
new `_daemon_` user for snaps.

This commit implements this support.
@pedronis pedronis self-requested a review August 3, 2023 08:56
@mvo5 mvo5 marked this pull request as ready for review August 3, 2023 10:26
Copy link
Collaborator

@pedronis pedronis left a comment

Choose a reason for hiding this comment

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

thanks, question about the preexisting spread tests

osutil/user.go Outdated Show resolved Hide resolved
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we change /tests/main/system-usernames to also test extensively daemon as snap_daemon is deprecated ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I think this would be a good idea. I will think a bit, either it needs to be a new snap or it needs to be a followup once the _daemon_ user is fully accepted (if we jsut add it as a second username to the existing snap).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually I have an idea and prepared https://github.com/snapcore/snapd/compare/master...mvo5:new-daemon-user-rocks-more-tests?expand=1 to allow to test within this PR, I may still do it in a followup for easier reviewing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And indeed #13060 will be used to update system-usernames but as a separate PR as it adds quite a bit of churn (but could of course merge into this one if desired :)

@mvo5 mvo5 added the Squash-merge Please squash this PR when merging. label Aug 3, 2023
@mvo5 mvo5 added this to the 2.61 milestone Aug 4, 2023
@mvo5 mvo5 merged commit 83c28ee into snapcore:master Aug 15, 2023
50 of 51 checks passed
@mvo5
Copy link
Contributor Author

mvo5 commented Aug 15, 2023

@degville we will need to update our docs once this is available in stable that this is the preferred way over snap_daemon.

alexmurray pushed a commit to alexmurray/snapd that referenced this pull request Oct 17, 2023
* many: add `_daemon_` as valid system username

With the recent adoption of the `_daemon_` user in the spec RK011
by the rocks team we should follow suite and also support the
new `_daemon_` user for snaps.

This commit implements this support.

* osutil: improve comments

* tests: improve system-users-are-created spread test

* many: tweak function naming/comment (thanks to Samuele)

* osutil: rename EnsureUserGroup->EnsureSnapUserGroup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Documentation 📖 Needs Samuele review Needs a review from Samuele before it can land Squash-merge Please squash this PR when merging.
Projects
None yet
4 participants