> > *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 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.
