Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Make sure gpio exported before apparmor setup #2
Conversation
| -} | ||
| - | ||
| -// ConnectedSlotSnippet - no slot snippets provided | ||
| -func (iface *GpioInterface) ConnectedSlotSnippet(plug *interfaces.Plug, slot *interfaces.Slot, securitySystem interfaces.SecuritySystem) ([]byte, error) { | ||
| switch securitySystem { |
jdstrand
Oct 5, 2016
Moving to PermanentSlotSnippet is fine. It'll be the core or gadget snap that is the providing side, so no big deal moving the exports IMO.
| switch securitySystem { | ||
| case interfaces.SecurityUDev: | ||
| // NOTE: nothing unexports this GPIO when the slot is disconnected but | ||
| // AFAIK this doesn't hurt. | ||
| - snippet := fmt.Sprintf(`ACTION=="add", SUBSYSTEM=="gpio", RUN+="/bin/echo %v > /syc/class/gpio/export"`, slot.Attrs["number"]) | ||
| + snippet := fmt.Sprintf(`SUBSYSTEM=="gpio", RUN+="/bin/sh -c '/bin/echo %v > /sys/class/gpio/export'"`, slot.Attrs["number"]) |
jocave
Oct 6, 2016
I removed ACTION==add because:
- the udev backend uses the command "udevadm trigger" (Note: no flags) to reload udev rules
- the default ACTION sent by the trigger command is "change" so the command in the original rule would not be matched on install of the snap
- we need to ensure the gpio is exported before any connection is made so the apparmor snippet can be created
By not specifying an action at all I think the rule is processed immediately as it only requires the device to be present. The guarantees that the gpio will be exported. The cost is that I don't believe it is actually possible to unexport a gpio with a rule like this in place. This may be a reasonable trade-off to guarantee the apparmor snippet can be created.
jocave
commented
Oct 6, 2016
|
@jdstrand Could you also comment on whether you think it is acceptable for the gpio to be exported even when there is no plug connected to the slot, which implies the resource is not in use. I think this is not ideal, but unfortunately required if we want to guarantee it is exported before ConnectedPlugSnippet is processed. |
jdstrand
commented
Oct 6, 2016
|
@jocave - in terms of security policy-- I think exported by snapd anywhere is pretty much ok since the plugging snap just needs the gpio to be there and the security policy will block access to an exported gpio to gpio-disconnected plugged snaps. As for whether it is a problem for the kernel or the system to have it exported even if unused, I have no opinion. It doesn't seem like it would be a big issue, but I'll defer a definitive answer to a gpio expert. |
added a commit
that referenced
this pull request
Nov 7, 2016
pushed a commit
that referenced
this pull request
Nov 25, 2016
|
Closing as I don't think we need this anymore, |
jocave commentedOct 5, 2016
No description provided.