I’m attempting to control LEDs from a webpage (and eventually other hardware from the device tree overlay). I’ve written a C program to toggle the onboard LED based on the arguments passed to it. This only works if you run it as root however. I’ve also installed lighttpd and have a php page running with a link to toggle the LED based on button press. To work around running as root, I added a setuid(0) to the C program and changed the ownership of the gcc output binary to root, then made the binary readable and executable by any user. The result is that the php page can control the LED, but I’m uncertain of how safe this set up is.
Is there a better (safer) way for me to be controlling hardware from a webpage with C? If not, what are my other options?
Let me know if I can provide you with any additional details.
Yes. You could implement a message passing bus (websockets for example)
which the C program responds to. Therefore you run your C program in the
background waiting for a message on the bus, then you get your web
application to send a message to the program telling it turn on/off an
LED. The C program runs as root and as such has control of the hardware
and your webapge never calls the C program, but only sends data on the
message bus, so as such it's a bit harder for anyone to do anything
untoward.
Ok perhaps I am missing something, and I by no means mean to be adversarial here. I am just curious, so If i am missing something please feel free to enlighten me.
What is the difference between using setuid(0) and having a web socks app running the app ? Here is my thinking. If you write the app/service correctly, all anyone is going to be able to do is switch on / off an LED. Yes, perhaps you do not want EVERYONE doing this, but how will this solution solve that specific problem ? Unless I am missing something . . . nothing can, short of having a user login screen for the web interface.
So I am not looking for an argument so much as enlightenment . . . as I have personally given this situation some thought over the last 6 or so months( being new to embedded Linux, and thus web appliances ).
My idea was to actually set environment variables to specific values for different occasions, then have an app/service read the values of the variables periodically. Whatever that is worth to anyone else . . .
Use Nodejs as there is a lot of examples for similar applications as yours and it is event driven.
It is easy to use websockets (socketio) as with php it was not so easy.
Ok perhaps I am missing something, and I by no means mean to be
adversarial here. I am just curious, so If i am missing something
please feel free to enlighten me.
What is the difference between using setuid(0) and having a web socks
app running the app ?
The web socket doesn't run the app, the app is always running, probably
started as a daemon from the init system, and accepts messages from the
web socket. Therefore there is no direct execution of a setuid binary
from the web interface.
Here is my thinking. If you write the app/service
correctly, all anyone is going to be able to do is switch on / off an
LED. Yes, perhaps you do not want *EVERYONE* doing this, but how will
this solution solve that specific problem ? Unless I am missing
something . . . nothing can, short of having a user login screen for the
web interface.
The issue isn't really with _who_ turns the LED on and off, that is a
application specific decision. The issue is with the ability to control
and execute a setuid binary from a possibly insecure, maybe even on the
open web application.
The web socket doesn’t run the app, the app is always running, probably started as a daemon from the init system, and accepts messages from the web socket. Therefore there is no direct execution of a setuid binary from the web interface.
Yeah sorry. My failed attempt at shorthand “speak”. IPC app of sorts is what I meant. Whether nodejs, C/C++, or whatever.
I think I do get the other point though. It is not what other people can do with your app that is intentional. It is what others may be able to do with your app unintentionally( perhaps intentional exploitation on their behalf, but something “you” did not foresee ).
Having to be root to diddle with the i/o pins seems questionable to me from a unix security standpoint.
Repeating my response to a similar question:
This is perhaps a more long-winded reply than you might want but in the general case I’m wondering why
the BBB is shipped with the device nodes in /dev for LEDs, and any other i/o stuff, set to be owned and
writable only by root. It seems to me that it would be nicer if there was a unix group that had write permission
to the device nodes and a udev rule that set up the devices to have write permission by that group. Different
devices could have different groups if you want to keep things narrowed down.
I’m new to web applications as well, hence the question. Clarification question: When using the web sockets protocol, the client and server are running on two different pieces of hardware, correct? If so, that’s great, because this is the general direction I am heading in with this exercise, however (and I should have been clear on this) my current situation is that I am hosting the php page on the bbb in the /home/ubuntu/public_html folder with the binary executable in that folder as well. In this case, would it be best to do what Rusty suggested and create a group with write permissions to the device nodes and a udev rule that set up the devices to have write permission by that group?
I would like to explore both options. After a quick Google search on web sockets, I came across libwebsockets. Would this project implement the web socket protocol you mentioned?
Any suggested reading material (even if I need to buy it) would also be appreciated.