/snapd

interfaces: fix udev tagging for hooks (2.29) #4146

Merged
merged 7 commits into from Nov 9, 2017

Conversation

Reviewers

@stolowski stolowski

@mvo5 mvo5

@pedronis pedronis

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
  2.29
5 participants
@zyga @codecov-io @stolowski @mvo5 @pedronis
@zyga
Contributor

zyga commented Nov 3, 2017

This is a backport of #4144 for 2.29; Original description follows.

This branch aims to fix udev tagging to support hooks in addition to apps that were added earlier.

There are three main patches here:

  • add spec.TagDevice method to udev.Specification, this automatically tags both apps and hooks
  • switch non-common interfaces to TagDevice, with exception of some special uses of AddSnippet
  • switch common interfaces to TagDevice, with some trivial changes to how that is defined.

The only remaining uses of spec.AddSnippet are special-cases that add large chunk of arbitrary
udev code that is not specifically aiming to tag a device.

This passes local unit testing, no testing was done on any hardware.
Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com

zyga added some commits Nov 3, 2017

@zyga
interfaces/udev: refactor acquisition of test data 
This will just allow us to add apps/hooks easily later.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
db92cf9
@zyga
interfaces/udev: add a way to udev-tag devices for all apps/hooks 
This patch introduces functionality similar to what other specification
types allow: the snippet is automatically added to all the apps and hooks
that affect the given plug or slot.

Udev is a bit special in that it allows arbitrary udev programs to be
injected (for instance, the network manager interface requires this)
but most interfaces don't need that generic functionality and instead
just want to tag a device so that all the apps associated with the
plug or slot have acess to it.

When we added hooks the udev backend was never updated to handle them
so we now noticed that hooks don't have any udev tagging at all.

With this new method we can use a much simpler API to do the right thing
while still retain the ability to add arbitrary free-form snippets
everywhere.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
b632328
@zyga
interfaces/builtin: use TagDevice instead of AddSnippet if possible 
This automatically handles both apps and hooks, leading to simpler and
more correct code. The only cases that still use AddSnippet are
injecting non-tagging expressions (udisks, modem-manager, etc).

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
748c5e1
@zyga
interfaces/builtin: convert common interfaces to new udev 
The "new" udev is where the TAG += ... part is handled automatically by
the common interface and now contains support for both apps and hooks.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

All checks have passed

7 successful checks
@mvo5
artful-amd64 — autopkgtest finished (success)
Details
@mvo5
artful-i386 — autopkgtest finished (success)
Details
continuous-integration/travis-ci/pr — The Travis CI build passed
Details
@mvo5
xenial-amd64 — autopkgtest finished (success)
Details
@mvo5
xenial-i386 — autopkgtest finished (success)
Details
@mvo5
xenial-ppc64el — autopkgtest finished (success)
Details
@mvo5
zesty-amd64 — autopkgtest finished (success)
Details
143d2d6

@zyga zyga added this to the 2.29 milestone Nov 3, 2017

zyga added some commits Nov 8, 2017

@zyga
Merge branch 'release/2.29' into backport/udev-hooks-2.29
This commit was created on GitHub.com and signed with a verified signature using GitHub’s key.
GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits
ad5d488
@zyga
Merge branch 'release/2.29' into backport/udev-hooks-2.29
This commit was created on GitHub.com and signed with a verified signature using GitHub’s key.
GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits
b029890
@mvo5

mvo5 reviewed Nov 9, 2017
View changes

This looks good and simplifies things which is great. OTOH quite a bit of churn so I have some questions inline.

interfaces/builtin/mir_test.go
@@ -139,8 +139,8 @@ func (s *MirInterfaceSuite) TestSecCompOnClassic(c *C) {
func (s *MirInterfaceSuite) TestUDevSpec(c *C) {
udevSpec := &udev.Specification{}
c.Assert(udevSpec.AddPermanentSlot(s.iface, s.coreSlot), IsNil)
- c.Assert(udevSpec.Snippets(), HasLen, 1)
- c.Assert(udevSpec.Snippets()[0], testutil.Contains, `KERNEL=="event[0-9]*", TAG+="snap_mir-server_mir"`)
+ c.Assert(udevSpec.Snippets(), HasLen, 5)
@mvo5

mvo5 Nov 9, 2017

Collaborator

Why did this change from 1 snippet to 5 snippets?

@zyga

zyga Nov 9, 2017

Contributor

Each snippet that tags a device is now a separate entry. Before they were one big blob.

@stolowski

stolowski Nov 9, 2017

Contributor

The test is a bit relaxed now with checking length only. I think it would be nice to have a 'Contains' check, like we do for others.

interfaces/builtin/modem_manager_test.go
@@ -207,9 +207,9 @@ func (s *ModemManagerInterfaceSuite) TestUsedSecuritySystems(c *C) {
udevSpec := &udev.Specification{}
c.Assert(udevSpec.AddPermanentSlot(s.iface, s.slot), IsNil)
- c.Assert(udevSpec.Snippets(), HasLen, 1)
+ c.Assert(udevSpec.Snippets(), HasLen, 2)
@mvo5

mvo5 Nov 9, 2017

Collaborator

Why did this change to two? One extra for a hook?

@zyga

zyga Nov 9, 2017

Contributor

Same as above. In the past this was one multi-line snippet.

interfaces/udev/spec.go
@@ -56,6 +70,8 @@ func (spec *Specification) AddConnectedPlug(iface interfaces.Interface, plug *in
UDevConnectedPlug(spec *Specification, plug *interfaces.Plug, plugAttrs map[string]interface{}, slot *interfaces.Slot, slotAttrs map[string]interface{}) error
}
if iface, ok := iface.(definer); ok {
+ spec.securityTags = plug.SecurityTags()
+ defer func() { spec.securityTags = nil }()
@mvo5

mvo5 Nov 9, 2017

Collaborator

Why are we doing this? This feels strange (and dangerous), I mean, if its something that should only be valid during the iface.UDevConnectedPlug() call maybe it should be an input parameter there instead? Actually we already pass "plug" in there, so why is UdevConntecedPlug not just using plug.SecurityTags() ?

@zyga

zyga Nov 9, 2017

Contributor

We do this in all the other backends. This is just making the API changes smaller and consistent with other backends.

@pedronis

pedronis Nov 9, 2017

Contributor

I agree, it merits a rethink at some point, but yes, I saw the other backends work like this as well

@pedronis

pedronis reviewed Nov 9, 2017
View changes

lgtm, some questions about SUBSYSTEM vs SUBSYSTEMS

interfaces/builtin/hidraw.go
+ spec.TagDevice(fmt.Sprintf(`SUBSYSTEM=="hidraw", KERNEL=="%s"`, strings.TrimPrefix(path, "/dev/")))
+ } else {
+ spec.TagDevice(fmt.Sprintf(`IMPORT{builtin}="usb_id"
+SUBSYSTEM=="hidraw", SUBSYSTEMS=="usb", ATTRS{idVendor}=="%04x", ATTRS{idProduct}=="%04x"`, usbVendor, usbProduct))
@pedronis

pedronis Nov 9, 2017

Contributor

is SUBSYSTEMS="usb" correct here? I remember jdstrand changed recently SUBSYSTEMS to SUBSYSTEM in some cases

@pedronis

pedronis Nov 10, 2017

Contributor

for other reasons I was reading the udev docs, it seems this means the hidraw subsystem under the usb devices, so it seems plausible

interfaces/builtin/serial_port.go
+ spec.TagDevice(fmt.Sprintf(`SUBSYSTEM=="tty", KERNEL=="%s"`, strings.TrimPrefix(path, "/dev/")))
+ } else {
+ spec.TagDevice(fmt.Sprintf(`IMPORT{builtin}="usb_id"
+SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="%04x", ATTRS{idProduct}=="%04x"`, usbVendor, usbProduct))
@pedronis

pedronis Nov 9, 2017

Contributor

is SUBSYSTEMS="usb" correct here? I remember jdstrand changed recently SUBSYSTEMS to SUBSYSTEM in some cases

interfaces/udev/spec.go
@@ -56,6 +70,8 @@ func (spec *Specification) AddConnectedPlug(iface interfaces.Interface, plug *in
UDevConnectedPlug(spec *Specification, plug *interfaces.Plug, plugAttrs map[string]interface{}, slot *interfaces.Slot, slotAttrs map[string]interface{}) error
}
if iface, ok := iface.(definer); ok {
+ spec.securityTags = plug.SecurityTags()
+ defer func() { spec.securityTags = nil }()
@mvo5

mvo5 Nov 9, 2017

Collaborator

Why are we doing this? This feels strange (and dangerous), I mean, if its something that should only be valid during the iface.UDevConnectedPlug() call maybe it should be an input parameter there instead? Actually we already pass "plug" in there, so why is UdevConntecedPlug not just using plug.SecurityTags() ?

@zyga

zyga Nov 9, 2017

Contributor

We do this in all the other backends. This is just making the API changes smaller and consistent with other backends.

@pedronis

pedronis Nov 9, 2017

Contributor

I agree, it merits a rethink at some point, but yes, I saw the other backends work like this as well

@mvo5
tests: disable xdg-open-compat test 
The test relies on the "old" snapd-xdg-open deb package. However
with the promotion of snapd 2.28.5 into xenial-updates the pervious
snapd-xdg-open version 0.0.0~16.04 is no longer available to
download. This means we can not run the test. Disable for now
until we find a way to fix it.
1892106
@stolowski

stolowski reviewed Nov 9, 2017
View changes

LGTM, with two remarks.

interfaces/builtin/hidraw.go
- spec.AddSnippet(fmt.Sprintf("SUBSYSTEM==\"hidraw\", KERNEL==\"%s\", TAG+=\"%s\"", strings.TrimPrefix(path, "/dev/"), tag))
-
- } else {
- spec.AddSnippet(udevUsbDeviceSnippet("hidraw", usbVendor, usbProduct, "TAG", tag))
@stolowski

stolowski Nov 9, 2017

Contributor

Why keeping udevUsbDeviceSnippet in utils, can we remove it as in #4144? Did you forget about cherry-picking something from the other branch?

@zyga

zyga Nov 9, 2017

Contributor

I wanted to stay minimal in this approach. I can pull more from 4144 if necessary.

interfaces/builtin/mir_test.go
@@ -139,8 +139,8 @@ func (s *MirInterfaceSuite) TestSecCompOnClassic(c *C) {
func (s *MirInterfaceSuite) TestUDevSpec(c *C) {
udevSpec := &udev.Specification{}
c.Assert(udevSpec.AddPermanentSlot(s.iface, s.coreSlot), IsNil)
- c.Assert(udevSpec.Snippets(), HasLen, 1)
- c.Assert(udevSpec.Snippets()[0], testutil.Contains, `KERNEL=="event[0-9]*", TAG+="snap_mir-server_mir"`)
+ c.Assert(udevSpec.Snippets(), HasLen, 5)
@mvo5

mvo5 Nov 9, 2017

Collaborator

Why did this change from 1 snippet to 5 snippets?

@zyga

zyga Nov 9, 2017

Contributor

Each snippet that tags a device is now a separate entry. Before they were one big blob.

@stolowski

stolowski Nov 9, 2017

Contributor

The test is a bit relaxed now with checking length only. I think it would be nice to have a 'Contains' check, like we do for others.

@codecov-io

codecov-io commented Nov 9, 2017 •
Edited 1 time

Codecov Report

Merging #4146 into release/2.29 will decrease coverage by 0.02%.
The diff coverage is 100%.

Impacted file tree graph

@@               Coverage Diff                @@
##           release/2.29    #4146      +/-   ##
================================================
- Coverage          75.6%   75.58%   -0.03%     
================================================
  Files               433      433              
  Lines             37277    37253      -24     
================================================
- Hits              28182    28156      -26     
- Misses             7124     7126       +2     
  Partials           1971     1971
Impacted Files Coverage Δ
interfaces/builtin/kvm.go 100% <ø> (ø) ⬆️
interfaces/builtin/bluetooth_control.go 100% <ø> (ø) ⬆️
interfaces/builtin/kernel_module_control.go 100% <ø> (ø) ⬆️
interfaces/builtin/raw_usb.go 100% <ø> (ø) ⬆️
interfaces/builtin/hardware_random_control.go 100% <ø> (ø) ⬆️
interfaces/builtin/fuse_support.go 100% <ø> (ø) ⬆️
interfaces/builtin/optical_drive.go 100% <ø> (ø) ⬆️
interfaces/builtin/physical_memory_observe.go 100% <ø> (ø) ⬆️
interfaces/builtin/time_control.go 100% <ø> (ø) ⬆️
interfaces/builtin/framebuffer.go 100% <ø> (ø) ⬆️
... and 29 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 01ac6ba...1892106. Read the comment docs.

@mvo5 mvo5 merged commit c8fb68f into snapcore:release/2.29 Nov 9, 2017
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@pedronis pedronis referenced this pull request Nov 10, 2017

Merged

interfaces: fix udev tagging for hooks #4144

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment