Permission denied using sysfs from i2c plug

device
1

Hi all
I’m trying to enable slots for i2c bus.

I declare a gadget with the following slot:

slots:
  i2c_leds:
    interface: i2c
    path: /dev/i2c-0

Because on the board there is a device /dev/i2c-0.
As root from a login shell I can enable the led connected on i2c bus with the command.

echo 255 > /sys/class/leds/pca963x:red/brightness.

If i make the same thing from snap with slot declared as follow:

plugs: [i2c]

after the connection of plug and slot with the command:

snap connect name_of_snap:i2c name_of_gadget:i2c-bus-0

I receive the following error :

audit: type=1400 audit(1492784346.956:299): apparmor=“DENIED” operation=“open” profile=“snap.test-led.led-blink” name=“/sys/devices/platform/soc/1c2b000.i2c/i2c-0/0-0062/leds/pca963x:red/brightness” pid=2504 comm=“led” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0

Any help about standard declaration of i2c bus interface or advice about the previous error?

2

well, your app doesnt seem to talk to /dev/i2c-0 at all there …

3

It seems like we should allow the plugging snap to do:

/sys/devices/platform/**.i2c/i2c-0/** rw,

This should be possible with the interface. I’ll take a look at it.

1 Like
4

Yes, we need to have read/write access to this path /sys/devices/platform/.i2c/i2c-0/.
Which interface we could use?
How we can define the slot in the gadget?

slots:
  leds:
     interface : xxxx
     parameter1 : xxxxx
     parameter2 : xyusys
     .
     .
     parameterN: zzzzzzz
5

My comment was saying that it is a bug in the i2s interface that the plugging snap is unable to access that path in sysfs and that I will fix that. Once fixed, you shouldn’t have to do anything else. In the mean time, you can workaround this issue by adding the above rule to your plugging snap’s security policy. Eg:

Add this to /var/lib/snapd/apparmor/profiles/snap.test-led.led-blink:

/sys/devices/platform/**.i2c/i2c-0/** rw,

then run:

$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.test-led.led-blink

Do keep in mind that snapd will occasionally rewrite the security policy, so you may have to add the rule back. Once the interface is fixed, you will not have to perform this workaround.

1 Like
6

Thanks @jdstrand.
Perhaps it is better to implement a regular expression that doesn’t match only i2c-0 but i2c-[0-9]* : in this manner the rule could support all i2c buses.

Nicolino

7

The idea is that we use /sys/devices/platform/**.i2c/i2c-0/** rw, when plugging i2c-0 and /sys/devices/platform/**.i2c/i2c-1/** rw,, when plugging i2c-1, and so on for i2c-N. This way a snap that plugs i2c-0 can manage only i2c-0 and another snap that plugs i2c-1 can manage only i2c-1 and they don’t interfere with each other.

8

https://github.com/snapcore/snapd/pull/3219

9

The PR above was merged.

10

Hi all,

I got a similar error in my snap when using i2c plug.

The gadget snap with the following slot:

i2c0:
   interface: i2c 
   path: /dev/i2c-0

The snap using the i2c plug as following:

apps:
iio-event-monitor:
command: iio_generic_buffer
plugs:
- iio
- hardware-observe
- i2c

After connection of the plug and slot:
$ snap connect demo-iio-tools:hardware-observe
$ snap connect demo-iio-tools:i2c name_of_gadget:i2c0
$ snap connect demo-iio-tools:iio name_of_gagdet:iio1

When the command issued, the error outputs from snap as:
$ sudo demo-iio-tools.iio-generic-buffer -a -N 1 -g
iio device number being used is 1
trigger-less mode selected
Enabling all channels
Enabling: in_accel_x_en
failed to open /sys/bus/iio/devices/iio:device1/scan_elements/in_accel_x_en
Failed to enable/disable in_accel_x_en
Enabling: in_accel_y_en
failed to open /sys/bus/iio/devices/iio:device1/scan_elements/in_accel_y_en
Failed to enable/disable in_accel_y_en
Enabling: in_accel_z_en
failed to open /sys/bus/iio/devices/iio:device1/scan_elements/in_accel_z_en
Failed to enable/disable in_accel_z_en
Enabling: in_timestamp_en
failed to open /sys/bus/iio/devices/iio:device1/scan_elements/in_timestamp_en
Failed to enable/disable in_timestamp_en
Still no channels after auto-enabling, giving up
Disabling: in_accel_x_en
failed to open /sys/bus/iio/devices/iio:device1/scan_elements/in_accel_x_en
Failed to enable/disable in_accel_x_en
Disabling: in_accel_y_en
failed to open /sys/bus/iio/devices/iio:device1/scan_elements/in_accel_y_en
Failed to enable/disable in_accel_y_en
Disabling: in_accel_z_en
failed to open /sys/bus/iio/devices/iio:device1/scan_elements/in_accel_z_en
Failed to enable/disable in_accel_z_en
Disabling: in_timestamp_en
failed to open /sys/bus/iio/devices/iio:device1/scan_elements/in_timestamp_en
Failed to enable/disable in_timestamp_en

The apparmor denied as:
[ 136.627749] audit: type=1400 audit(1503654228.739:311): apparmor=“DENIED” operation=“open” profile=“snap.demo-iio-tools.iio-generic-buffer” name="/sys/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/scan_elements/in_accel_x_en" pid=3278 comm=“iio_generic_buf” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0
[ 136.627863] audit: type=1400 audit(1503654228.739:312): apparmor=“DENIED” operation=“open” profile=“snap.demo-iio-tools.iio-generic-buffer” name="/sys/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/scan_elements/in_accel_y_en" pid=3278 comm=“iio_generic_buf” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0
[ 136.627953] audit: type=1400 audit(1503654228.739:313): apparmor=“DENIED” operation=“open” profile=“snap.demo-iio-tools.iio-generic-buffer” name="/sys/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/scan_elements/in_accel_z_en" pid=3278 comm=“iio_generic_buf” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0
[ 136.628042] audit: type=1400 audit(1503654228.739:314): apparmor=“DENIED” operation=“open” profile=“snap.demo-iio-tools.iio-generic-buffer” name="/sys/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/scan_elements/in_timestamp_en" pid=3278 comm=“iio_generic_buf” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0
[ 136.628749] audit: type=1400 audit(1503654228.739:315): apparmor=“DENIED” operation=“open” profile=“snap.demo-iio-tools.iio-generic-buffer” name="/sys/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/scan_elements/in_accel_x_en" pid=3278 comm=“iio_generic_buf” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0
[ 136.628838] audit: type=1400 audit(1503654228.739:316): apparmor=“DENIED” operation=“open” profile=“snap.demo-iio-tools.iio-generic-buffer” name="/sys/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/scan_elements/in_accel_y_en" pid=3278 comm=“iio_generic_buf” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0
[ 136.628926] audit: type=1400 audit(1503654228.739:317): apparmor=“DENIED” operation=“open” profile=“snap.demo-iio-tools.iio-generic-buffer” name="/sys/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/scan_elements/in_accel_z_en" pid=3278 comm=“iio_generic_buf” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0
[ 136.629012] audit: type=1400 audit(1503654228.739:318): apparmor=“DENIED” operation=“open” profile=“snap.demo-iio-tools.iio-generic-buffer” name="/sys/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/scan_elements/in_timestamp_en" pid=3278 comm=“iio_generic_buf” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0

The iio sysfs path is symlink to i2c sysfs path:
/sys/bus/iio/devices/iio:device1 -> …/…/…/devices/platform/80860F41:00/i2c-0/i2c-SMO8A90:00/iio:device1/

I checked the code of snapd i2c interface. The apparmor profile using:

/sys/devices/platform/**.i2c/%s/** rw,

On my system, the sysfs of i2c path is not match this condition which as:

/sys/devices/platform/80860F41:00/i2c-0/

I had tried to manually update the apparmor profile of my snap with:

/sys/devices/platform/**/%s/** rw,

This rule works well for my snap.
I think my profile rule is not a good one.
Any suggestion for snapd to support the this case of i2c sysfs?

Thanks

11

Hey, thank you for your report. I think we should correct the rule to allow this pattern as well. @jdstrand - what do you think?

Note that some of the denials above were for iio, not i2c, try connecting that interface as well.

12

This is definitely a bug and the paths need to be adjusted …

13

the problem here is that the two interfaces are cross-linking on the sysfs level (the iio device links to the i2c entry) … the rules need to be adjusted to allow such setups.

14

This is definitely a policy bug, so +1 on fixing it.

As for the iio denials, they are below the i2c-N directory so when the policy bug is fixed, this would just work.

15

This actually is a superset of the existing rule. It isn’t wrong, but I think if we can, we can add this rule instead:

/sys/devices/platform/*/%s/** rw,
1 Like
16

https://github.com/snapcore/snapd/pull/3811

17

In my case, I was suppose to use iio plug only for accessing iio device. When I got denied errors, I just tried to find out the errors were about iio sysfs are link to i2c, so I added another i2c plug.
That’s not straightforward for developing snaps which using iio plug.
Any solution for iio slot to support with symlink in sysfs?

18

Ok, then we need to also update the iio interface. I’ll do that now.

20

https://github.com/snapcore/snapd/pull/3826

21

Tested the snap 2.27.5+git352.186fdc0~ubuntu16.04.1 with this pull request works well for iio interface!
Thank you @jdstrand and everyone!

2 Likes