Yes, they are. And I think my partially-successful solution is udev based.
I copied this rule from the robot project I linked to before:
# Install in: /etc/udev/rules.d/
# from cnobile2012@ github
#
KERNEL=="gpio*", SUBSYSTEM=="gpio", ACTION=="add",
PROGRAM="/bin/fix_udev_gpio.sh"
and this script, with modifications (marked with '# added this line')
#!/bin/bash
#
# This file will change the user, group and permissions in both the
# /sys/devices/virtual/gpio and /sys/class/gpio path directories.
#
# DO NOT change the order of the commands below, they are optimized so that
# commonly created files and directories are changed first.
#
chown -R debian:gpio /sys/devices/virtual/gpio
chown -R debian:gpio /sys/class/gpio
chown -R debian:gpio /sys/devices/bone_capemgr.* # added this line
chown -R debian:gpio /sys/devices/ocp.* # added this line
find /sys/devices/virtual/gpio -type d -exec chmod 2775 {} \;
find /sys/devices/virtual/gpio -name "direction" -exec chmod 0660 {} \;
find /sys/devices/virtual/gpio -name "edge" -exec chmod 0660 {} \;
find /sys/devices/virtual/gpio -name "value" -exec chmod 0660 {} \;
find /sys/devices/virtual/gpio -name "active_low" -exec chmod 0660 {} \;
chmod 0220 /sys/class/gpio/export
chmod 0220 /sys/class/gpio/unexport
chmod 0664 /sys/devices/bone_capemgr.*/slots # added this line
chmod -R 0770 /sys/devices/ocp.* # added this line
find /sys/devices/virtual/gpio -name "uevent" -exec chmod 0660 {} \;
find /sys/devices/virtual/gpio -name "autosuspend_delay_ms" -exec chmod
0660 {} \;
find /sys/devices/virtual/gpio -name "control" -exec chmod 0660 {} \;
Still seeing just a steady light, not PWM. Should be seeing four flashes a
second with a 33% duty cycle.
On Mon, Feb 8, 2016 at 7:45 PM William Hermans <yyrk...@gmail.com> wrote:
> It seems as though their using sysfs:
> https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/c_pwm.c#L68-L77
>
> On Mon, Feb 8, 2016 at 6:23 PM, William Hermans <yyrk...@gmail.com> wrote:
>
>> OK, so assuming your issue doing the above - only works as root, and
>> you'd like it to work as a regular user too . . .
>>
>> You need to figure out how the Adafruit_BBIO library accesses the pins,
>> and go from there. Does it use sysfs, or /dev/mem/ ?
>>
>> If the library uses sysfs. Then I would think you'd need to create a udev
>> rule to add a group to your desired asset. In order for the pin path to
>> have the appropriate permissions every time that asset is enabled through
>> pinctrl. Which in your case I'd assume every reboot only.
>>
>> A bit of advice however . . . if this library uses /dev/mem/ to access
>> the pins . . . **DO NOT** adjust permissions on /dev/mem/. As that could
>> give anyone in that group direct access to any physical address on the CPU.
>> In short. they could pretty much do anything they'd want.
>>
>> If you're confident you can control access to the board, my concern above
>> is less of a problem. As I tend to look at security issues of this nature
>> as if one is already compromised at a regular user level. If the board is
>> rooted . . . well then . . .heh it's moot.
>>
>> On Mon, Feb 8, 2016 at 3:48 PM, John Stoner <j...@forelight.com> wrote:
>>
>>> and when I do the above as root it blinks as it should.
>>>
>>> On Mon, Feb 8, 2016 at 4:44 PM John Stoner <j...@forelight.com> wrote:
>>>
>>>> (env) app@beaglebone:/opt/reactor_controller/src$ uname -a
>>>> Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015
>>>> armv7l GNU/Linux
>>>> (env) app@beaglebone:/opt/reactor_controller/src$ cat /etc/dogtag
>>>> BeagleBoard.org Debian Image 2015-03-01
>>>>
>>>> (env) app@beaglebone:/opt/reactor_controller/src$ python
>>>> Python 2.7.3 (default, Mar 14 2014, 17:55:54)
>>>> [GCC 4.6.3] on linux2
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>> >>> import Adafruit_BBIO.PWM as PWM
>>>> >>> PWM.start('P8_13', 33, 4) # this turns the light on steady
>>>> >>> PWM.stop('P8_13') # this turns it off
>>>> >>> PWM.cleanup()
>>>>
>>>> I am using the latest Adafruit_BBIO library, source available at
>>>>
>>>> https://github.com/adafruit/adafruit-beaglebone-io-python
>>>>
>>>> Anything else you need?
>>>>
>>>> On Mon, Feb 8, 2016 at 4:39 PM William Hermans <yyrk...@gmail.com>
>>>> wrote:
>>>>
>>>>> *I call my success partial because I can get a test LED to turn on,
>>>>>> but I can't get it to flash using PWM.*
>>>>>>
>>>>>> *Any ideas why that would be?*
>>>>>>
>>>>>
>>>>> No . . . Because you've given no pertinent details. We'd need to know
>>>>> a few things, but kernel version used, method used for attempting to
>>>>> control said PWM, code, etc. All will help. So, if you want help, help us,
>>>>> help you.
>>>>>
>>>>> On Mon, Feb 8, 2016 at 11:33 AM, <j...@forelight.com> wrote:
>>>>>
>>>>>> This is John, the guy with the question Drew to above on the Adafruit
>>>>>> board. (Thanks Drew for starting this conversation here.)
>>>>>>
>>>>>> The problem is, this is part of a commercial application. My code
>>>>>> will be reading and writing to the GPIOs and doing various things,
>>>>>> communicating data to remote systems... I anticipate adding a fair bit of
>>>>>> complexity. I'd hate to make a bug that blew something important away or
>>>>>> something like that. I am generally leery of unnecessary privilege
>>>>>> escalation.
>>>>>>
>>>>>> So I could
>>>>>>
>>>>>> - sudo my entire application, which would be the same as running as
>>>>>> root;
>>>>>> - partition my application and have it invoke the code that
>>>>>> interfaces directly to the GPIOs as sudo in some way (via shell?);
>>>>>> - go by way of the PRUs;
>>>>>> - change permissions;
>>>>>> - some other way.
>>>>>>
>>>>>> I did have partial success changing the permissions on relevant
>>>>>> files, ala
>>>>>>
>>>>>> https://github.com/cnobile2012/RobotControl/tree/master/contrib
>>>>>>
>>>>>> which uses udev to set up permissions (not that I understand udev
>>>>>> either.)
>>>>>>
>>>>>> I call my success partial because I can get a test LED to turn on,
>>>>>> but I can't get it to flash using PWM.
>>>>>>
>>>>>> Any ideas why that would be?
>>>>>>
>>>>>> On Sunday, February 7, 2016 at 10:00:01 AM UTC-6, Mike Bell wrote:
>>>>>>>
>>>>>>> On 02/06/2016 12:51 AM, Brian Anderson wrote:
>>>>>>>
>>>>>>>
>>>>>>> My comments are really to do with what I perceive as best practices
>>>>>>> on how one would approach building systems that are "security
>>>>>>> conscious".
>>>>>>> Of course, "convenience" may direct us in different directions during
>>>>>>> development. I am not sure what you are trying to imply by "safe" as in
>>>>>>> protecting the GPIOs from misuse. I don't actually see any way to
>>>>>>> accomplish that. What I do think one can do is to be aware of security
>>>>>>> considerations and not unnecessarily present an attack surface that can
>>>>>>> compromise the entire system.
>>>>>>>
>>>>>>>
>>>>>>> *Using sudo seems much less secure as it exposes the application to
>>>>>>>>> being exploited for security flaws. And since the application is
>>>>>>>>> running as
>>>>>>>>> root, it has access to everything.*
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, we have a device on a system that can potentially cause
>>>>>>>> physical damage to external hardware when something like a wrong GPIO
>>>>>>>> state
>>>>>>>> is toggled, or such. How would sudo be less secure in this context?
>>>>>>>>
>>>>>>>
>>>>>>> It wouldn't. And that is not my point. I am not talking about how
>>>>>>> to protect the GPIOs from "bad behaved" programs that are "trusted" as
>>>>>>> implied by the fact that they are running as a normal user in the group
>>>>>>> that has access to those GPIOs. If an application is trusted (is a
>>>>>>> member
>>>>>>> of the appropriate group or for that matter can sudo), it is a hopeless
>>>>>>> task to protect the GPIOs from misuse. What I am trying to point out is
>>>>>>> that running an app as "root" (sudo, set uid, whatever) exposes a
>>>>>>> security
>>>>>>> attack vector...a vector that has access to _all_ system resources. I
>>>>>>> would claim that it is an unnecessary exposure...from a security point
>>>>>>> of
>>>>>>> view. YMMV when it comes to "convenience".
>>>>>>>
>>>>>>>
>>>>>>>> In fact under certain conditions it would be less safe using groups.
>>>>>>>>
>>>>>>>
>>>>>>> How would an application running at a non-root level using groups to
>>>>>>> access protected resources be less "safe" than an application running as
>>>>>>> root using sudo?
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Also, "root has access to everything" is wrong. Reread what I've
>>>>>>>> written above about running specific commands through sudo.
>>>>>>>>
>>>>>>>
>>>>>>> Errr, an application running as root, by definition, has access to
>>>>>>> _all_ system resources. The fact that you are limiting just a single
>>>>>>> application/user to run sudo doesn't limit the attack surface for that
>>>>>>> application. If your root application is compromised in some way, then
>>>>>>> the
>>>>>>> entire system can be compromised. Running as a normal user does not
>>>>>>> present the same attack surface...its much smaller and sandboxed by the
>>>>>>> kernel. Running as root affords no protection enforcement by the
>>>>>>> kernel.
>>>>>>>
>>>>>>> ba
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Feb 5, 2016 at 6:05 PM, Brian Anderson <b...@nwlink.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Err, why?
>>>>>>>>>
>>>>>>>>> Groups are frequently used to restrict access to resources.
>>>>>>>>> Android exploits groups for permissions and to sandbox applications.
>>>>>>>>> And
>>>>>>>>> the kernel enforces access.
>>>>>>>>>
>>>>>>>>> Using sudo seems much less secure as it exposes the application to
>>>>>>>>> being exploited for security flaws. And since the application is
>>>>>>>>> running as
>>>>>>>>> root, it has access to everything.
>>>>>>>>>
>>>>>>>>> But maybe I'm missing something?
>>>>>>>>>
>>>>>>>>> ba
>>>>>>>>>
>>>>>>>>> Brian,
>>>>>>>
>>>>>>> This is a great summation of the issue!
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>> --
>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>> ---
>>>>>>
>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "BeagleBoard" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to beagleboard+unsubscr...@googlegroups.com.
>>>>>>
>>>>>
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>> --
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> ---
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "BeagleBoard" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/beagleboard/Ca7QDUwv72g/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> beagleboard+unsubscr...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/Ca7QDUwv72g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
