Other Prevent user from exiting program

So I've been searching online for a while and cannot find any solutions.

I've working on something that will work similar to a kiosk. This being the case I need to prevent a user from exiting the application once the system boots up into it. Is there a script or something that I can use to prevent this from happening?

The idea is that the system will boot up, auto-login and immediately start my program in full screen until I exit it by giving a secret exit code in the application itself. I just need a way to prevent users from exiting my program using other methods like keyboard input or the like.
 
See signal(3). You can't block signals caused by "the environment" or just a crashing program, but you can block signals caused by interactive actions. You could start with something like this:
Code:
#include <signal.h>
[...]
sigaction(SIGHUP, SIG_IGN, 0);
sigaction(SIGINT, SIG_IGN, 0);
sigaction(SIGTSTP, SIG_IGN, 0);
Please refer to signal(3) to learn which signals you should ignore, it really depends on your application.
 
I've working on something that will work similar to a kiosk. This being the case I need to prevent a user from exiting the application once the system boots up into it.
I think you need to think about the ambitious little hacker who might be able to sit at your kiosk and try and get it to reboot.
So plan for that. Someone will get in. What happens when they do?
Make it so the only thing that can happen is your kiosk reboots back to opening screen.
Use NanoBSD so there is nothing saved.
Epoxy the usb ports. drill the screw heads out. Use shock circuit if someone tries to open the box.

Regarding the software kill switch I think a physical lock with a switch behind it is more appropriate.
Just my opinion.
 
GUI or console?

If you give the user a text console and a normal keyboard, it is hard to prevent them from pressing keys that cause signals. Some of the signals you can catch and recover from in "the program"; other signals you can disable using stty. But some keyboard stuff is hard to disable, such as Ctrl-Alt-Del or Scroll Lock.

If it is a GUI, then you can use or configure a window manager that restricts them to exactly the one window you want to show, and prevent any other applications from getting keyboard focus.

Ideally, if you can do it without keyboard, just with touchscreen or physical buttons (connected to something like GPIO pins), it's even safer.
 
I don't like the whole idea at all.
Since I cannot imagine any application useful to users why to do so to mee it smells badly like somekind of trap (either to want users to get into it, or run yourself into it), if not an attempt for a bad hack....it just don't feel good to me.

However:
Because I cannot imagine any useful app it doesn't mean there is none.
So here's my advice from the sight of system's engineering:
Think it over and through, carefully! Very carefully!
There is a very high chance you'll produce a systematic error, because you want to lever safety measures built-in not for no reasons.
(In contrast to so called trivial errors, systematic errors cannot be fixed.)

For something like that you must have absolutely no errors at all.
Which does not only include: "Yeah, yeah! I doublechecked the codeI. It's completely bugfree."
I'm talking about definitions, specifications and design.
That's where systematic errors come from.
When those are done like "yeah, yeah, we'll see to that later..." - that's nearly a guarantee to produce a systematic error.

Imagine:
Something goes wrong / doesn't work anymore / unforseen happens...
- and any developing engineer will tell you:
it will.
Especially things you did not even dreamed of.
Then what?
Your user cannot do anything, 'cause he's out.
Game Over!
 
I think you need to think about the ambitious little hacker who might be able to sit at your kiosk and try and get it to reboot.
So plan for that. Someone will get in. What happens when they do?
Make it so the only thing that can happen is your kiosk reboots back to opening screen.
Use NanoBSD so there is nothing saved.
Epoxy the usb ports. drill the screw heads out. Use shock circuit if someone tries to open the box.

Regarding the software kill switch I think a physical lock with a switch behind it is more appropriate.
Just my opinion.
I was considering using NanoBSD. It seems like a decent option since the system files will be read only. I plan on only giving access to a keyboard or mouse but maybe a touch screen and an onscreen keyboard will be more appropriate. That was the kind of kid I was. Always wanting to see how things worked and what I could get them to do. I'll try to look at it in a way that I would've as a kid and see how I could've been stopped.

See signal(3). You can't block signals caused by "the environment" or just a crashing program, but you can block signals caused by interactive actions. You could start with something like this:
Code:
#include <signal.h>
[...]
sigaction(SIGHUP, SIG_IGN, 0);
sigaction(SIGINT, SIG_IGN, 0);
sigaction(SIGTSTP, SIG_IGN, 0);
Please refer to signal(3) to learn which signals you should ignore, it really depends on your application.
I will definitely check this out. Thank you. It's just an interactive user space. I was next going to look into a way to prevent them from traversing upwards in the directory tree beyond a certain point. I think using the signal blocking technique may be a good mix.

I don't like the whole idea at all.
Since I cannot imagine any application useful to users why to do so to mee it smells badly like somekind of trap (either to want users to get into it, or run yourself into it), if not an attempt for a bad hack....it just don't feel good to me.

However:
Because I cannot imagine any useful app it doesn't mean there is none.
So here's my advice from the sight of system's engineering:
Think it over and through, carefully! Very carefully!
There is a very high chance you'll produce a systematic error, because you want to lever safety measures built-in not for no reasons.
(In contrast to so called trivial errors, systematic errors cannot be fixed.)

For something like that you must have absolutely no errors at all.
Which does not only include: "Yeah, yeah! I doublechecked the codeI. It's completely bugfree."
I'm talking about definitions, specifications and design.
That's where systematic errors come from.
When those are done like "yeah, yeah, we'll see to that later..." - that's nearly a guarantee to produce a systematic error.

Imagine:
Something goes wrong / doesn't work anymore / unforseen happens...
- and any developing engineer will tell you:
it will.
Especially things you did not even dreamed of.
Then what?
Your user cannot do anything, 'cause he's out.
Game Over!
It's just a small program that would show off products and services. I know I've seen Window's systems used in a "kiosk mode" type of way. I've also seen things go catastrophically wrong with it as well. It's why I'm using my daily driver (FreeBSD) figuring with it's configurability and the ability to access source I could make something that works a bit better with at least a lower chance of screwing up.
 
I was considering using NanoBSD. It seems like a decent option since the system files will be read only. I plan on only giving access to a keyboard or mouse but maybe a touch screen and an onscreen keyboard will be more appropriate.
I did have troubles getting Xorg/OpenBox to run using NanoBSD. I didn't persue it too far because I was fighting touch screen drivers back then.

My NanoBSD build philosophy is to build the machine with regular FreeBSD then copy out all the config files for NanoBSD to use. So build appliance manually then copy configs in along with the needed packages (from pkg cache of appliance) on to your NanoBSD build directories.

Xorg needs to have RW space. So memory disk for temp is where I was working.
 
I bought some of these tiny machines hoping to get some kiosks out the door.
Uses N455 Atom. Touch works.
Add it to my list of half done things.
You can get a media player working without Xorg. That's as far as I got. Looping video with mplayer on NanoBSD.
 
I did have troubles getting Xorg/OpenBox to run using NanoBSD. I didn't persue it too far because I was fighting touch screen drivers back then.

My NanoBSD build philosophy is to build the machine with regular FreeBSD then copy out all the config files for NanoBSD to use. So build appliance manually then copy configs in along with the needed packages (from pkg cache of appliance) on to your NanoBSD build directories.

Xorg needs to have RW space. So memory disk for temp is where I was working.
Ok, I know there are alternatives to xorg. Maybe I'll look into them. So from your previous post you just install FreeBSD to the end device then run NanoBSD scripts? Or you install NanoBSD then install the applications on the end device?

I bought some of these tiny machines hoping to get some kiosks out the door.
Uses N455 Atom. Touch works.
Add it to my list of half done things.
You can get a media player working without Xorg. That's as far as I got. Looping video with mplayer on NanoBSD.
I'll check those out. Thank you.
 
So from your previous post you just install FreeBSD to the end device then run NanoBSD scripts? Or you install NanoBSD then install the applications on the end device?
 
Thanks. That's what I've been planning to use. Seems like my best option since PicoBSD and MiniBSD seem to both be dead projects.
 
So from your previous post you just install FreeBSD to the end device then run NanoBSD scripts?
No. So I do a full install, get it setup. Then copy config files out to NanoBSD build box.
This is not required but it is a good QA check. Does your setup work? Y/N

From there I make a custom nanobsd.conf for the appliance/kiosk.
You can name it whatever you want. Here is an example.

Under /usr/src/tools/tools/nanobsd/ is where your build configuration lives.
You can make custom directories underneath for each build platform.
Note the compiled files end up under /usr/obj/. This includes your image file.
You can manipulate the ./files directory to hold your build config files. The whole disk layout.
You create the directory structure exactly as found on your Full Install.
See function: customize_cmd cust_install_files

Include all packages used in txz format including pkg in the directory you designate.
As you can see Oliver uses a add ports() function for applications. I use a custom pkg function.
There are many ways to build.
 
Back
Top