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