Permissions on sysfs ina3221 files for JP451


We wrote some code for our TX2, JP333 based product that read the ina3221 sysfs files and reported the values on our interface.

We did it from C, but the bash equivalent is:

nvidia@CHARM249008:~$ cat /sys/bus/i2c/drivers/ina3221x/0-0040/iio_device/in_current0_input
nvidia@CHARM249008:~$ ls -l /sys/bus/i2c/drivers/ina3221x/0-0040/iio_device/in_current0_input
-rw-r--r-- 1 root root 4096 Apr  2 02:53 /sys/bus/i2c/drivers/ina3221x/0-0040/iio_device/in_current0_input

We’re just trying to port the code to Xavier NX on JP451 and can’t because the file permissions are different. For example:

nvidia@CHARM250268:~$ cat /sys/bus/i2c/drivers/ina3221x/7-0040/iio\:device0/in_current0_input
cat: '/sys/bus/i2c/drivers/ina3221x/7-0040/iio:device0/in_current0_input': Permission denied
nvidia@CHARM250268:~$ ls -l /sys/bus/i2c/drivers/ina3221x/7-0040/iio\:device0/in_current0_input
-rw------- 1 root root 4096 Mar 22 15:07 /sys/bus/i2c/drivers/ina3221x/7-0040/iio:device0/in_current0_input

Should/can we use a different approach?

I don’t want to make our application run as root just to be able to read these files.


I’ve never tried this, but maybe udev rules can be added to change the permissions from 0300 (read is bit 1, write is the 2 bit, sum is 0x3) to 0311. This isn’t hot plug, so I don’t know if this is even a valid method, but it probably will work. Consider that all of /sys files are not real files, they exist only in RAM and are really drivers pretending they are files as a method to talk to user space. Otherwise you probably need to run the application as root.

Anyone here ever updated /sys file permissions in another way?

Thanks for your input.

I suspect it’s not that important to us. I’ll talk to the rest of the team and see if they agree we can drop it as a feature.

If not, I guess we’ll need to create a service that can run between our main app and sysfs.

I get the impression from the Internet, that these changes are being made because any information can be used by bad actors to gain an insight into what the system is doing. Fair enough! :-)


That’s mostly correct, but I’ll add that because the files are a driver, and not actual files, that the code within the driver has to be set up to use different permissions. Was your driver coded and set up with original permissions for a reason? Maybe changes will work, but maybe there are unexpected code consequences. Those files are logic and you’re calling a program, not writing or reading a file.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.