*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 ). On Tue, Feb 11, 2014 at 3:16 AM, Jack Mitchell <m...@communistcode.co.uk>wrote: > On 10/02/14 21:34, William Hermans wrote: > > Jack, > > > > 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. > > Cheers, > > -- > Jack Mitchell (j...@embed.me.uk) > Embedded Systems Engineer > Cambridgeshire, UK > http://www.embed.me.uk > -- > > -- > 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/groups/opt_out. > -- 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/groups/opt_out.
