-
Notifications
You must be signed in to change notification settings - Fork 562
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
Conversation
Codecov Report
❗ 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
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 8 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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.
09d324a
to
b054546
Compare
There was a problem hiding this 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
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
@degville we will need to update our docs once this is available in stable that this is the preferred way over snap_daemon. |
* 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
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_