File Permissions for exported GPIO pins changed in Kernel 4.1.6

[herbertkoenig]

Hi,

before my latest update, when exporting a GPIO pin like:
echo 17 > /sys/class/gpio/export
the file /sys/class/gpio/gpio17/direction
would be read/writeable by owner root and group gpio. Same holds for the value file and the gpio17 folder.

In the 4.1.6 kernel this has changed as follows:
The gpio17 folder can be read an written by everyone.
The file /sys/class/gpio/gpio17/direction is now owned by root and in group root (not gpio) and is readable by everyone and changeable only by the owner. Same for the value file.

old kernel:
Linux herpi1 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux
new kernel:
Linux herpi4 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l GNU/Linux

[popcornmix]

Looks like something may have changed in the later kernel where
/sys/devices/soc/*.gpio/gpio is now /sys/devices/platform/soc/*.gpio/gpio

Can you try editing:
/lib/udev/rules.d/60-python-pifacecommon.rules and
/lib/udev/rules.d/60-python3-pifacecommon.rules (if they both exist) to be:

KERNEL=="spidev*", GROUP="spi", MODE="0660"
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"

Reboot and report back if that fixes it.

[herbertkoenig]

Hi,

seems to work, I'll report back with more detail soon.

Thanks,

Herbert

Am 24.08.2015 um 16:33 schrieb popcornmix:

Looks like something may have changed in the later kernel where
|/sys/devices/soc/.gpio/gpio| is now
|/sys/devices/platform/soc/.gpio/gpio|

Can you try editing:
|/lib/udev/rules.d/60-python-pifacecommon.rules| and
|/lib/udev/rules.d/60-python3-pifacecommon.rules| (if they both exist)
to be:

|KERNEL=="spidev_", GROUP="spi", MODE="0660" SUBSYSTEM=="gpio_",
PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R
770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio &&
chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio
/sys/devices/platform/soc/.gpio/gpio && chmod -R 770
/sys/devices/platform/soc/.gpio/gpio'" |

Reboot and report back if that fixes it.

—
Reply to this email directly or view it on GitHub
#1117 (comment).

[herbertkoenig]

Hi,

I can confirm the fix solves my problem.

The differences in the file permissions of the folder
/sys/class/gpio/gpio17
I thought I still spotted were due to me misinterpreting the slightly
changed file permissions dialog in the new kernel.

Thanks for the fix, I'll report it in the Raspi Forum where I initially
raised the topic.

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=118879

Cheers,

Herbert

Am 24.08.2015 um 16:33 schrieb popcornmix:

Looks like something may have changed in the later kernel where
|/sys/devices/soc/.gpio/gpio| is now
|/sys/devices/platform/soc/.gpio/gpio|

Can you try editing:
|/lib/udev/rules.d/60-python-pifacecommon.rules| and
|/lib/udev/rules.d/60-python3-pifacecommon.rules| (if they both exist)
to be:

|KERNEL=="spidev_", GROUP="spi", MODE="0660" SUBSYSTEM=="gpio_",
PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R
770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio &&
chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio
/sys/devices/platform/soc/.gpio/gpio && chmod -R 770
/sys/devices/platform/soc/.gpio/gpio'" |

Reboot and report back if that fixes it.

—
Reply to this email directly or view it on GitHub
#1117 (comment).

[mauritslamers]

I found that after upgrading to Raspian jessie the udev rules files mentioned above did not exist. Creating the first one and then doing a restart solved the issue.

[popcornmix]

@mauritslamers
How did you upgrade? Clean install or by changing apt sources and dist upgrade?
On a clean jessie image the permissions seem okay to me.

[christophfroehlich]

I updated via apt-get upgrade to 4.1.7+ and had the same problem. fixing 60-python-pifacecommon.rules did work for me.

[mauritslamers]

@popcornmix I upgraded by changing apt sources and then running an apt-get dist-upgrade.

[popcornmix]

I think you'll probably have to manually edit if you manually upgraded, but @XECDesign can confirm if an upgrade path is planned.
A clean install of jessie should have the correct udev rules.

[mauritslamers]

@popcornmix In order to edit, the file should exist in the first place. In my case it didn't, but creating it, adding the content as mentioned above fixed the problem of not being able to use the GPIO as the pi user.

[XECDesign]

I'm not sure that an upgrade path is planned for this particular issue. It would still require the user to install a package which would handle such things. However, we can create a raspberrypi-sys-mods package for future releases.

[rpakdel]

FYI, I did a clean install of Raspbian Jessie from https://www.raspberrypi.org/downloads/raspbian/ last week.

The permissions don't work (Node.js gpio access gives permission error when not run as root). The udev rules files also don't exist. I've added the files manually (copied from my working Wheezy install) and rebooted but they're still not working (I gave up quickly).

[XECDesign]

People looking at /lib/udev/rules.d/ and assuming the files are missing are looking in the wrong place.

The rules are in /etc/udev/rules.d/99-com.rules

I don't know anything about node.js or what exact method you're using to access GPIO. Perhaps it's a /dev/mem mmap method which will always need root?

[rpakdel]

Thanks for pointing me to the right direction. The 99-com.rules file is missing setting the group permissions on /sys/devices/soc. Appending the line below to PROGRAM fixes this

chown -R root:gpio /sys/devices/soc/*.gpio/gpio && chmod -R 770 /sys/devices/soc/*.gpio/gpio

Test:

pi@raspberrypi /sys/class/gpio $ ls -la
total 0
drwxrwx--- 2 root gpio 0 Oct 14 04:56 .
drwxr-xr-x 38 root root 0 Oct 14 04:46 ..
-rwxrwx--- 1 root gpio 4096 Oct 14 04:51 export
lrwxrwxrwx 1 root gpio 0 Oct 11 09:17 gpiochip0 -> ../../devices/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 unexport

pi@raspberrypi /sys/class/gpio $ echo 17 > export
pi@raspberrypi /sys/class/gpio $ ls -la gpio17/
total 0
drwxrwx--- 3 root gpio 0 Oct 14 04:56 .
drwxrwx--- 4 root gpio 0 Oct 14 04:56 ..
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 active_low
lrwxrwxrwx 1 root gpio 0 Oct 14 04:56 device -> ../../../20200000.gpio
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 direction
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 edge
drwxrwx--- 2 root gpio 0 Oct 14 04:56 power
lrwxrwxrwx 1 root gpio 0 Oct 14 04:56 subsystem -> ../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 uevent
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 value

[XECDesign]

@rpakdel What does uname -a say?

[rpakdel]

Linux raspberrypi 3.18.0-trunk-rpi #1 PREEMPT Debian 3.18.5-1~exp1+rpi19 (2015-08-08) armv6l GNU/Linux

I had to switch to the Debian kernel so that I could compile USB wifi module. I wasn't about to try to get the 4.1.7 headers. Sorry.

[XECDesign]

Ah, then it's not supported here and isn't an issue as far as Raspbian's maintainer is concerned either. The reason this issue was raised was because the necessary rules changed with the move to 4.1.

[jsiei97]

To sum up what the current state:

On 2015-05-05-raspbian-wheezy.zip using default kernel
Linux regulator 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l GNU/Linux

Export works (since group is gpio)

cj@regulator ~ $ echo 27 > /sys/class/gpio/export
cj@regulator ~ $ ls -lh /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4.0K nov 15 09:02 export
lrwxrwxrwx 1 root gpio    0 nov 15 09:01 gpio27 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio27
lrwxrwxrwx 1 root gpio    0 jan  1  1970 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4.0K nov 15 09:04 unexport

But when I look at the direction file, it is not ok, since it was created with group root.

cj@regulator ~ $ echo "out" > /sys/class/gpio/gpio27/direction
-bash: /sys/class/gpio/gpio27/direction: Permission denied
cj@regulator ~ $ ls -lh /sys/devices/platform/soc/20200000.gpio/gpio/gpio27
total 0
-rw-r--r-- 1 root root 4.0K nov 15 09:02 active_low
lrwxrwxrwx 1 root root    0 nov 15 09:02 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4.0K nov 15 09:02 direction
-rw-r--r-- 1 root root 4.0K nov 15 09:02 edge
lrwxrwxrwx 1 root root    0 nov 15 09:02 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4.0K nov 15 09:02 uevent
-rw-r--r-- 1 root root 4.0K nov 15 09:02 value

So the default installation is broken and needs to be fixed.

Then on this system there is 3 files that does almost does the same thing.

• /etc/udev/rules.d/99-com.rules
• /lib/udev/rules.d/60-python-pifacecommon.rules
• /lib/udev/rules.d/60-python3-pifacecommon.rules

@XECDesign from this point what was the recommended fix? Since @rpakdel was using a non default kernel this issue seems to be paused?

[rpakdel]

Coincidentally my SD card got corrupted and I reinstalled Raspian Jessie image with the Raspian kernel (no changes. I gave up on compiling wifi drivers). Export of GPIO pins as non-root works fine.

[XECDesign]

There are 2 separate issues here:

1. The paths have changed between the kernel versions
2. The custom udev rules don't currently belong to a package. They're just put there when creating the image. This means that they can't be updated automatically.

rpkadel was running into 1. @jsiei97, you're running into 2. The solution for that was given in the forum thread (https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=118879#p828766)

[dlech]

I would say that the issue 1) is not that the paths have changed - that is compliant with sysfs-rules.txt.

Position of devices along device chain can change.

Rather the issue is that the udev rules chooses to ignore the advice from sysfs-rules.txt.

Here is a udev rule that I came up with that does the same sort of thing. It uses the $devpath udev variable instead of explicitly specifying the path (which may change). https://github.com/ev3dev/ev3dev-rules/blob/ev3dev-jessie/debian/ev3dev-rules.ev3dev.udev

So, I think that this issue with regard to the kernel is invalid and can be closed.

[XECDesign]

thanks, that rule seems promising.

[blubberblase]

hey guys,

I recently did an $ apt-get update and $ apt-get upgrade
and I also somehow destroied my file, which was using the gpio "on/off"-module (which was working fine before).
So I tried make my setting's for using it again.
But I always run in an Error when I try to use the .write(..) function.

[Error: EPERM: operation not permitted, write] errno: -1, code: 'EPERM', syscall: 'write'

I check and only found this rules-document /etc/udev/rules.d/99-com.rules
which says
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'" UBSYSTEM=="input", GROUP="input", MODE="0660" SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660" SUBSYSTEM=="spidev", GROUP="spi", MODE="0660" SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

I compared it with what you haven written here, but could find the difference.
And nop, on my system is no "/sys/devices/soc/*.gpio/gpio" path. so I didn't added this staff.

so can someone tell me what am I doing wrong or what I am missing?

[XECDesign]

The latest raspberrypi-ui-mods package uses $devpath. I haven't tested on 3.18 kernel, but it should work. Okay to close?

[deadprogram]

Seems like this problem still exists on the latest released Jessie Lite v4.4, from my testing.