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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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, <[email protected]> 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 <[email protected]> >>>>>>> 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 [email protected]. >>>>> >>>> >>>>> 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 >>>> [email protected]. >>>> 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 [email protected]. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
