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.
