-
Notifications
You must be signed in to change notification settings - Fork 592
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
snapstate: do not allow classic mode for strict snaps #6039
Conversation
Right now it is possible to install a strictly confined snap as in classic confinement mode with: ``` snap install --classic test-snapd-tools ``` This should not work.
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.
+1
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.
Some unit tests are broken now:
FAIL: snapstate_test.go:483: snapmgrTestSuite.TestInstallClassicConfinementFiltering
snapstate_test.go:501:
c.Assert(err, IsNil)
... value *errors.errorString = &errors.errorString{s:"classic confinment requested for a non classic confined snap"} ("classic confinment requested for a non classic confined 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.
I tried to quickly fix the failure but I was unable to, I think this requires a deeper look. Some of the tests seem to indicate that we wanted the feature to operate this way too.
Well, when we added classic I seem to recall we went over the combinations discussing which we wanted to work and which we didn't :-) I get it that we got one of them wrong, but that means we probably need to fix tests as well |
Also also: we need an error kind, so the clients can catch the error and offer suggestions / helpful error messages instead of the arcane server message |
…don't support classic Mock classic snap support so that all unit test can are run everywhere Signed-off-by: Maciej Borzecki <[email protected]>
overlord/snapstate/check_snap.go
Outdated
@@ -129,6 +129,10 @@ func (e *SnapNeedsClassicSystemError) Error() string { | |||
// determine whether the flags (and system overrides thereof) are | |||
// compatible with the given *snap.Info | |||
func validateFlagsForInfo(info *snap.Info, snapst *SnapState, flags Flags) error { | |||
if flags.Classic && !info.NeedsClassic() { | |||
return fmt.Errorf("classic confinment requested for a non classic confined 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.
confinement
I'll try to push fixes for the unit tests |
Signed-off-by: Maciej Borzecki <[email protected]>
…end unit tests Allow upgrading from classic to strict on update, but keep blocking the transition from strict to classic. Update unit tests for installation and updates. Signed-off-by: Maciej Borzecki <[email protected]>
@mvo5 the unit tests should pass now. I updated the handling of classic flag when the snap is transitioning from classic to strict or reverse on refresh. Hopefully, I haven't broken anything while doing so. |
The test failures in spread look real:
|
…ting classic Signed-off-by: Maciej Borzecki <[email protected]>
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.
+1
Please fix the typo before merging.
|
Signed-off-by: Maciej Borzecki <[email protected]>
131723d
to
b9c8127
Compare
Co-Authored-By: mvo5 <[email protected]>
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.
Nice! Just one question inline about infoToUpdate. Also wondering we should add an errot type for this, iirc @chipaca suggested this.
@@ -731,6 +731,11 @@ func UpdateMany(ctx context.Context, st *state.State, names []string, userID int | |||
|
|||
params := func(update *snap.Info) (string, Flags, *SnapState) { | |||
snapst := stateByInstanceName[update.InstanceName()] | |||
updateFlags := snapst.Flags | |||
if !update.NeedsClassic() && updateFlags.Classic { |
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.
👍
@@ -1118,7 +1123,12 @@ func Update(st *state.State, name, channel string, revision snap.Revision, userI | |||
} | |||
|
|||
params := func(update *snap.Info) (string, Flags, *SnapState) { | |||
return channel, flags, &snapst | |||
updateFlags := flags | |||
if !update.NeedsClassic() && updateFlags.Classic { |
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.
Slightly sad that our code requires to duplicate this with the code above.
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 given that infoForUpdate is also changed (below) - do we need this change here or is the change in infoForUpdate sufficient?
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.
Snap info is verified twice, once in infoForUpdate()
and then once again in doUpdate()
. I'm beginning to think that maybe verifying flags in infoForUpdate()
is actually superfluous.
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.
@bboozzoo Thanks for checking this! Would be great if you could double check, the less code the better :)
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.
Dropped the part in infoForUpdate()
.
Validation of snap.Info with current set of flags is already done in doUpdate() for all code paths. No need to do it earlier when obtaining snap.Info for update. Signed-off-by: Maciej Borzecki <[email protected]>
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.
👍 (can't approve this as I create the PR)
I agree with @chipaca about wanting an error kind for this, client.ErrKindSnapNotClassic would fit the mold I think (to live parallel to the *SnapNeeds* errors etc) |
I can look into adding the error once I'm back. |
Introduce a separate error kind for a case when an attempt to install a non classic snap with classic confinement is made. Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
@chipaca can you take another look? |
Fwiw, looks good to me, thanks for the changes! |
cmd/snap/error.go
Outdated
@@ -191,6 +191,8 @@ usually confined to, which may put your system at risk. | |||
|
|||
If you understand and want to proceed repeat the command including --classic. | |||
`) | |||
case client.ErrorKindSnapNotClassic: | |||
msg = i18n.G(`snap %q is not a classic confined 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.
Not a blocker, but I think this is not a good error message for a user.
|
|
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.
Extra +1 for good luck
Signed-off-by: Maciej Borzecki <[email protected]>
@robert-ancell This PR adds a new error kind that may be relevant for snapd-glib |
@mvo thanks! In canonical/snapd-glib@57a93bb |
Right now it is possible to install a strictly confined snap as in
classic confinement mode with:
This should not work.