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

snapstate: do not allow classic mode for strict snaps #6039

Merged
merged 15 commits into from
Nov 13, 2018

Conversation

mvo5
Copy link
Contributor

@mvo5 mvo5 commented Oct 24, 2018

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.

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.
Copy link
Contributor

@zyga zyga left a comment

Choose a reason for hiding this comment

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

+1

Copy link
Contributor

@zyga zyga left a 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")

zyga
zyga previously requested changes Oct 25, 2018
Copy link
Contributor

@zyga zyga left a 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.

@chipaca
Copy link
Contributor

chipaca commented Oct 26, 2018

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

@chipaca
Copy link
Contributor

chipaca commented Oct 26, 2018

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]>
@@ -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")
Copy link
Contributor

Choose a reason for hiding this comment

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

confinement

@bboozzoo
Copy link
Contributor

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]>
@bboozzoo
Copy link
Contributor

@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.

@zyga zyga dismissed their stale review October 26, 2018 15:08

Needs re-review

@zyga
Copy link
Contributor

zyga commented Oct 26, 2018

The test failures in spread look real:

    - google:amazon-linux-2-64:tests/main/install-errors:noreexec

Copy link
Contributor

@zyga zyga left a 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.

@zyga
Copy link
Contributor

zyga commented Oct 26, 2018

2018-10-26 17:53:12 Error executing google:amazon-linux-2-64:tests/main/refresh:classic_fake : 
-----
+ . /home/gopath/src/github.com/snapcore/snapd/tests/lib/systems.sh
+ '[' fake = fake ']'
+ is_core_system
+ [[ amazon-linux-2-64 == ubuntu-core-* ]]
+ return 1
+ '[' true = false ']'
+ [[ test-snapd-classic-confinement =~ classic ]]
+ case "$SPREAD_SYSTEM" in
+ echo 'When the snap is refreshed'
When the snap is refreshed
+ snap refresh --channel=edge test-snapd-classic-confinement
error: cannot perform the following tasks:
- Mount snap "test-snapd-classic-confinement" (3) (snap "test-snapd-classic-confinement" requires classic confinement)

@bboozzoo bboozzoo force-pushed the no-classic-for-strict branch from 131723d to b9c8127 Compare October 29, 2018 09:20
Copy link
Contributor Author

@mvo5 mvo5 left a 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 {
Copy link
Contributor Author

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 {
Copy link
Contributor Author

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.

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 given that infoForUpdate is also changed (below) - do we need this change here or is the change in infoForUpdate sufficient?

Copy link
Contributor

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.

Copy link
Contributor Author

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 :)

Copy link
Contributor

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]>
Copy link
Contributor Author

@mvo5 mvo5 left a 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)

@pedronis
Copy link
Collaborator

pedronis commented Nov 7, 2018

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)

@bboozzoo
Copy link
Contributor

bboozzoo commented Nov 7, 2018

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]>
@pedronis pedronis requested a review from chipaca November 9, 2018 10:10
@bboozzoo
Copy link
Contributor

bboozzoo commented Nov 9, 2018

@chipaca can you take another look?

@mvo5
Copy link
Contributor Author

mvo5 commented Nov 9, 2018

Fwiw, looks good to me, thanks for the changes!

@@ -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`)
Copy link
Contributor

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.

@pedronis
Copy link
Collaborator

pedronis commented Nov 9, 2018

<pedronis> Chipaca: given that #6039 is introducing that error, maybe that fact that is not good is a blocker :)
<pedronis> Chipaca: this is 2.37 material, if you have suggestion for a better error, please suggest
<mborzecki> Chipaca: pedronis: how about `classic confinment requested, but snap %q is not a classic confined snap` ?
<mborzecki> the original version by mvo was `classic confinment requested for a non classic confined snap', maybe a variant of this could work
<pedronis> mborzecki: I think Chipaca is suggesting that it's one of those longer messages, explaining a bit the concept as well
<pedronis> I'm honestly a bit too tired right now to make a suggestion
<pedronis> like the ones for SnapNeeds*
<pedronis> maybe the error needs to carry the actual confinement to help produce a better error
<pedronis> message
<pedronis> as well

@pedronis
Copy link
Collaborator

pedronis commented Nov 9, 2018

<Chipaca> mborzecki: pedronis: i'm very tired so not sure this suggestion is any good, but something like "snap %q is not compatible with --classic" would spell out exactly what the user did wrong

Copy link
Contributor

@chipaca chipaca left a 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

@mvo5
Copy link
Contributor Author

mvo5 commented Nov 13, 2018

@robert-ancell This PR adds a new error kind that may be relevant for snapd-glib

@mvo5 mvo5 merged commit ba566fe into canonical:master Nov 13, 2018
@robert-ancell
Copy link
Contributor

@mvo thanks! In canonical/snapd-glib@57a93bb

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.

6 participants