element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Benefits of Membership
    • Achievement Levels
    • Members Area
    • Personal Blogs
    • Feedback and Support
    • What's New on element14
  • Learn
    Learn
    • Learning Center
    • eBooks
    • STEM Academy
    • Webinars, Training and Events
    • More
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • More
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • More
  • Products
    Products
    • Arduino
    • Dev Tools
    • Manufacturers
    • Raspberry Pi
    • RoadTests & Reviews
    • Avnet Boards Community
    • More
  • Store
    Store
    • Visit Your Store
    • Choose Another Store
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
Raspberry Pi
  • Products
  • More
Raspberry Pi
Forum Anyone know how to access RasPi GPIO without sudo?
  • Blog
  • Forum
  • Documents
  • Events
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Raspberry Pi requires membership for participation - click to join
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Verified Answer
  • Replies 14 replies
  • Answers 2 answers
  • Subscribers 145 subscribers
  • Views 2070 views
  • Users 0 members are here
  • raspberry_pi
Related

Anyone know how to access RasPi GPIO without sudo?

johnbeetem
johnbeetem over 9 years ago

I've finally gotten around to playing with RasPi GPIOs, using Gert van Loo and Dom's C code at the RasPi Wiki.  It works fine, except that you have to run the executable as root or use sudo to access /dev/mem.

 

Does anyone here know how to access /dev/mem as a normal user?

  • Reply
  • Cancel
  • Cancel

Top Replies

  • johnbeetem
    johnbeetem over 7 years ago in reply to Former Member +2

    Roger Wolff wrote:

     

    Now back to your problem...
    If you make a little program that allows you to manipulate just the GPIO outputs, that won't allow you to cause all the other mischief you'd be able to…

  • rew
    rew over 9 years ago in reply to Arjan +1 verified

    Unix has a "security model". As a normal users you can do stuff, but you should not be able to access other people's files on the same computer. And as a user you should not be able to cause the computer…

  • Former Member
    Former Member over 9 years ago in reply to Former Member +1 suggested

    Keith Chiem wrote:

     

    $ sudo chown pi /dev/mem

    That will not work.  As well as any access controls imposed by the filesystem, you also need to have capability CAP_SYS_RAWIO to open the /dev/mem device.  So you…

Parents
  • Former Member
    0 Former Member over 9 years ago

    Does anyone here know how to access /dev/mem as a normal user?

    Don't do that.  There's a device driver for the gpios that can be made to expose them under /sys/class/gpio. Access is comparitively slow, but at least it's safer than messing with /dev/mem

     

    You can find documentation for 'gpiolib' towards the end of Documentation/gpio.txt in any recent linux kernel source tree. There you'll find out how to export particular gpios to userspace. 

    Note that you likely still need to chown some files under /sys/class/gpio to allow user access after exporting them as root. Roger is quite right on the security model - consider that gpio's will often be connected to something that sensitive and you should understand why you normally need root to access them.

     

    Here's a trivial example in bash

     

    echo 55 > /sys/class/gpio/export

    echo out > /sys/class/gpio/gpio55/direction

    echo 1 > /sys/class/gpio/gpio55/value

     

    however note that 55 isn't a valid value unless you've added a gpio expander like the mcp23008 I'm using, and recompiled the kernel appropriately.

    • Cancel
    • Up 0 Down
    • Reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • johnbeetem
    0 johnbeetem over 9 years ago in reply to Former Member

    selsinork wrote:

     

    Does anyone here know how to access /dev/mem as a normal user?

    Don't do that.  There's a device driver for the gpios that can be made to expose them under /sys/class/gpio. Access is comparitively slow, but at least it's safer than messing with /dev/mem

    Thank you for the suggestions, but I don't want slow.  This is more out of principle (what others call "pig-headedness") than any real need for my LEDs to blink one million times faster than my eye can resolve.  I figure, hey, it's my computer and what's the point of having memory-mapped I/O if I can't access it as memory?  If you're going to go through several layers of condoms to protect your GPIOs, you might as well be using a mainframe and where's the fun in that?

     

    OTOH, I do accidentally delete files from time to time and I'd hate to accidentally delete a system file or directory while being root, so I don't like to stay root for more milliseconds than necessary.  OTOH, I find I've almost never screwed up a system by accessing the wrong memory address, probably because I'm more careful doing the latter.  Back when I was programming PDP-11s, I caused any number of bus errors but never accidentally wrote bad words into the hard drive control registers.

     

    So here's something else I tried: I changed the permissions on /dev/mem to the dreaded 666 to allow anyone to access it.  That didn't work.  I also tried changing permissions on /dev/mem to 660 and added myself to the "kmem" group.  That didn't work either.  I'm a little nervous about changing the ownership of /dev/mem to myself since I'd worry that root might want to be the owner somewhere else.

    • Cancel
    • Up 0 Down
    • Reply
    • Verify Answer
    • Cancel
Reply
  • johnbeetem
    0 johnbeetem over 9 years ago in reply to Former Member

    selsinork wrote:

     

    Does anyone here know how to access /dev/mem as a normal user?

    Don't do that.  There's a device driver for the gpios that can be made to expose them under /sys/class/gpio. Access is comparitively slow, but at least it's safer than messing with /dev/mem

    Thank you for the suggestions, but I don't want slow.  This is more out of principle (what others call "pig-headedness") than any real need for my LEDs to blink one million times faster than my eye can resolve.  I figure, hey, it's my computer and what's the point of having memory-mapped I/O if I can't access it as memory?  If you're going to go through several layers of condoms to protect your GPIOs, you might as well be using a mainframe and where's the fun in that?

     

    OTOH, I do accidentally delete files from time to time and I'd hate to accidentally delete a system file or directory while being root, so I don't like to stay root for more milliseconds than necessary.  OTOH, I find I've almost never screwed up a system by accessing the wrong memory address, probably because I'm more careful doing the latter.  Back when I was programming PDP-11s, I caused any number of bus errors but never accidentally wrote bad words into the hard drive control registers.

     

    So here's something else I tried: I changed the permissions on /dev/mem to the dreaded 666 to allow anyone to access it.  That didn't work.  I also tried changing permissions on /dev/mem to 660 and added myself to the "kmem" group.  That didn't work either.  I'm a little nervous about changing the ownership of /dev/mem to myself since I'd worry that root might want to be the owner somewhere else.

    • Cancel
    • Up 0 Down
    • Reply
    • Verify Answer
    • Cancel
Children
  • Former Member
    0 Former Member over 9 years ago in reply to johnbeetem

    Thank you for the suggestions, but I don't want slow.  This is more out of principle (what others call "pig-headedness") than any real need for my LEDs to blink one million times faster than my eye can resolve.  I figure, hey, it's my computer and what's the point of having memory-mapped I/O if I can't access it as memory?  If you're going to go through several layers of condoms to protect your GPIOs, you might as well be using a mainframe and where's the fun in that?

    At this point I'll respectfully suggest you're looking at it the wrong way. You have two conflicting requirements, you should pick one and be done with it. Either run as root and accept that you can delete files either by using 'rm -rf /' or by scribbling the wrong stuff into /dev/mem, or run as a normal user and accept those limitations.

     

    You should also realise that the same gpio driver that you don't want to use 'owns' the memory locations you want to manually write to and as such you can't prevent the kernel from changing those locations behind your back. (you could try compiling out the gpio driver, but as the sdcard driver depends on it you'll have other problems).

    This is part of the compromise you sign up to by running linux as your OS. You are of course free to do other things by not running linux, going for a bare metal approach and treating the Pi like an arduino.

     

    I also agree with the sentiment that it's your computer and you should be able to do what you like. For that reason, especially on something like the Pi, I suggest simply running as root and forgetting about the 'problem' altogether     I have effectively just one user on my Pi - root (there are a few more, but no others can login and they're only there to keep stuff that expects them happy)

    • Cancel
    • Up 0 Down
    • Reply
    • Verify Answer
    • Cancel
Element14

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2022 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • Facebook
  • Twitter
  • linkedin
  • YouTube