hpr-knowledge-base/hpr_transcripts/hpr4569.txt

Episode: 4569
Title: Kiosk with guest mode on Linux
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4569/hpr4569.mp3
Transcribed: 2026-07-31 16:14:07 (official HPR transcript)

---

This is Hacker Public Radio Episode 4569, for 2026-02-05
Today's show is entitled, "Kiosk with guest mode on Linux"
The host is Klaatu and the duration is 00:23:57
The flag is Clean, and the license is CC-BY-SA
The summary is "Use GDM and either a ramdisk or systemd to create a guest profile with self-removing user data"
Hey, everybody. It's glad to. There used to be a sort of a really convenient mode or add-on.
I guess to most Linux distributions, I feel. And it was this guest mode. It was a guest user profile.
You could enable this through a package frequently called X guest. And it would add a user to your login screen called guest.
So you could let a friend or colleague use your computer as a guest. And they could, they would get their own profile.
They could do whatever they want to, you know, within within the bounds of what a user is normally allowed to do on the system.
And then when they log out, every all trace of their activity is simply discarded.
It's just removed. And so every time you log into the guest profile, it's a fresh profile. It's brand new as if no one had ever been there before.
It was a really useful thing because you don't really, I mean, a lot of people will just hand their laptop to someone else.
And just, sure, you can use the web browser or whatever. I never liked doing that for lots of different reasons.
But I mean, primarily, because I just don't want people accidentally or maliciously, but I didn't,
I didn't let people who I suspected of malice use my laptop. But accidental, just erasure of my data,
or even just messing up my environment, just moving a panel somewhere that I don't want it,
or adding an icon to a desktop by accident, by dragging it out of a folder or a menu or something.
So it's just kind of, it's safer and easier to give someone their own guest account.
Now, we don't really use X11 so much anymore. I mean, some of us do. I actually do on my slack
machine. I'm still running X11, but a lot of people have switched over to Wayland. And so the X guest package,
which does as its name sort of hints rely on Xorg, that doesn't really work. I mean, you can install the
package. You can try to log in as guest, but it doesn't deliver a desktop as I've recently found out.
So I, I needed a guest account for a project that I was working on. And the advantage of the
guest account was exactly as I mentioned. The total erasure of all user data, indiscriminate,
just don't need it anymore. When someone logs out, we want to lose all of that data. Now,
this particular project was brought to me by a friend in New York, upstate, New York.
And it's for a library. So the library wants to have guest computers that people can use,
surf the internet, search the card catalog, or whatever you call it, the stacks, whatever. And then
when they log out, or they could do other stuff too, they can research online, they can write
stuff in LibreOffice, they could, I don't know, do graphics and gimp or einkscape or whatever. You know,
like whatever is available on the computer, they have access to that. They can save files,
maybe to save it to the internal hard drives so that they can then move it to some cloud account,
or whatever mechanism. I'm not sure if they have physically as attached storage or not. But when
they log out, everything that they've done needs to be erased for privacy purposes, for data
security purposes, for all of the reasons. So my friend who's volunteering at this library, it was
looking for a solution to provide this guest account or this kiosk mode experience on just some
Linux distribution. I had Fedora 43 on hand, so I decided to kind of poke around and see what
I could come up with because I had it in my head that GDM, the Genome Display Manager, that's the
screen that you get when you first log in, or when you're about to log in to a Linux graphical desktop,
that's running the Genome Desktop. You generally see the GDM. It's not always true. They might use
their own display manager. They might use a different one that then activates Genome. But a lot of times
the Genome sort of the default setup for a Genome Linux distribution, a Linux distribution using Genome,
is going to be GDM for the login screen, and then that will pass you over to the Genome desktop
after you enter your credentials. So I had it in my head that GDM was aware of session states.
And I thought I wonder if GDM has some kind of mechanism to trigger shell scripts or applications
or actions of some type based on the session state. Yes, it does. Turns out that it absolutely
does. So the default behavior of GDM is to track I think four or five different states. There's
init. That's the initial state. The initialization state post log in. So that's the moment that
someone has entered their correct, authentic, their correct credentials. Pre-session. So that's the
time before the session actually begins. Like moments before the session begins. And then post
session, which is once the log out command or the log out signal has been sent to the Genome
desktop. Each of these states has a directory located in slash Etsy slash GDM. And it turns out
that when you place a, for instance, a shell script named default with a capital D default in one of
those directories, GDM runs the script when that state is reached. So if you want something to trigger
upon that at the post session stage, then you'd put a shell script called default into slash
Etsy slash GDM slash post session. In fact, there's there may already be a shell script there
called default with some sample commands or maybe just a header comment telling you what the
script does. But it, that's all you need to do is put default into slash Etsy slash GDM slash
post session in this case for, for a log out action to trigger that shell script. The shell script
needs to be executable. I think it needs to be a valid shell script. And that's it. Otherwise,
you have full control. You, you can do whatever you want to in that script. It's pretty cool. So
to trigger actions, for instance, to clean up a user's environment upon log out, I created
slash Etsy slash GDM slash post session slash default. You can add whatever actions you want
to run on log out in this script. And in my case, I wanted to clear everything all all data.
Couple of different ways to do this. I chose the really sort of hefty choice of just removing
dash RF dollar sign home. Now, I didn't do that outright because that would then clear every
user's data upon log out, bad idea. Instead, I mean, that might be what you want. But for me,
I just wanted the guest account to have the home removed. So I did an if statement, if space
square bracket space, quote, dollar sign user, close quote equals quote library guest,
close quote space square bracket, semicolon, then Rm space dash RF space dollars, uh, yeah,
quote dollar sign home, close quote, and then F i to end the if statement and then exit zero to
signal that yes, we are exiting with success. And so that's comparing the the environment variable
dollar sign user, which, which GDM specifically does recognize it uses. Even though I think that
this script is being run as root, I'm pretty sure it respects, it retains the old dollar sign
user value of the session. So I'm comparing dollar sign user to the the string library guest. And
that's a that's the name of the user that I'm going to create as my guest account. It's going to be
library guest. If your guest account is just called guest or my guest or some, you know, a
toxic penguin, whatever, then that's the name, that's the string you would want to use when
comparing dollar sign user to the name. The point is that this if statements, if statement ensures that
the the the home directory dollar sign home is only removed if the active user that has triggered
the log out signal is library guest. If you as an admin user log in as, I don't know, admin or
plateau or gore to whatever your name is. And then you log out that's not going to trigger this because
your dollar sign user variable would not be assigned to library guest in that case. It would be
plateau or admin or gore to whatever your name is. So that protects you from accidentally clearing
out your entire home directory. That's very important. You really need to test that before engaging
in this solution because otherwise you could just clear out every manner of home directory on your
system and that would be quite upsetting if that's not what you wanted. Okay, so the the GDM
solution is pretty simple. I mean, there's no library guest user yet and that is the next thing
that you have to configure here because you do need to think about, and the reason I don't have
a library guest user on my system yet it might my pretend system that I'm talking about yet
is because we have to decide where that library user is going to, where the home directory is
going to actually be located. I mean, it's going to be in slash home slash library guest. I get that.
But what file system and the reason this came to mind is because I was thinking about the, you know,
the erasure of all data on log out and I thought, well, what happens when a user doesn't log out?
There are lots of reasons a user might not log out. The system might be shut down out from under
them. The admin might send a shutdown signal or they might shut down. They might reboot.
There might be a power outage that the box could just lose power and shut off. None of those
involved a log out signal sent to GDM. That means that this erasure that the removal of the home
directory wouldn't be triggered, which would mean that data that you've claimed is going to remain
private and deleted upon the end of the session is now retained in this hard drive. So obviously,
you'd want to encrypt your hard drive to add a little bit of extra protection there. But it's
still didn't quite feel right to retain that data because that's a snapshot of that data, right? I mean,
that could be that that that's not great. So how can we get that data to absolutely go away
upon shutdown, reboot, or even a power outage? Well, I think the easiest way to do that is to just place
the entire home directory or the the guest users home directory in a RAM disk, a temporary file
system, saved to RAM. Now, if you've got a lot of RAM, you know, like, I don't know, eight gigabytes.
There's probably a lot in this context because you don't really need that much space in the home
directory. It's going to be a it's a temporary thing where people are just going to be browsing
the internet probably may be saving a couple of documents. Like literally you could probably make a
two gigabyte home directory and be fine. But, I mean, you have six gigs to run your system on.
But, I mean, obviously, more is better, so maybe 16 gigs, 20 gigs, 24 gigs, whatever. So you
got a lot of gigs of RAM, then you could just use a RAM disk and creating a temporary file system
on all the Linux's I know is pretty simple. You just add a line to your slash FS,
don't know slash Etsy slash FS tab. The line goes a little something like this.
Tmpfstmps and then tab slash home slash library guest. That's what that's the the
mount point we we're creating here. tab tmpfs. That's the file system type. tab rw's comma no
s uid comma no dev comma size equals 2g or 4g or however big you want to make that partition or
that mount point rather and then tab 0 space 0. You can look up all of those options in the
man page of sfst tab. But, essentially, that's making a mount point called slash home slash library
guest right within your RAM as if though it was a hard drive on your system. It's only being ram.
It's only going to last as long as it has power. So anything saved to that drive disappears
upon reboot or shut down or a power outage. I think two gigs honestly is probably plenty of space
for just internet browsing and making a few documents here and there. But you could make it bigger
if you anticipate that your guest users are going to be doing more than than those basic activities.
I have a RAM disk on my computer that I use for my downloads folder and it is I think eight
gigabytes and that's plenty of space for a bunch of you know a reasonable number of large downloads
and it all just goes away when I shut down. Okay, next you need to actually create the library
guest user. You have to do this manually because of no system setting panel that I've seen lately
lets you do advanced tasks like assigning a different home directory to a user. So if you do it manually
you can do that. I do that with user add. Sudo user add space dash dash home dash dur slash home
slash library guest. So we're just pointing the home dur to the the RAM disk that we're creating.
And then space library guest. Cool. Now that user exists you do get a warning here that the home
directory slash home slash library guest already exists or if you don't get a warning about that
I guess I forgot to mention after adding it to fs tab you would want to mount slash home slash
library guest. Then you can do the user add command. As I said you'll get a warning it might tell you
that it already exists. It's not going to copy any files from scale directory into it. It's okay
all of that's going to be created automatically upon login. So it doesn't actually matter. Those
are just warnings that are not errors. You can ignore them. You do need to create a password for the
library guest. I was playing around with automatic logins for library guest. Not sure if I love it
because eventually people are going to log out and then they're going to get back it. So I don't know.
I just I think probably just creating a simple password just kind of makes sense. So Sudo password
or PASS WD space library guest and then give it whatever you know password you want to give it.
And then that's it. That's the guest account. It's on a ram disk. It'll go away if the power is cut
or if the user manages to get into a reboot or a shutdown state and of course because of GDM
it also gets wiped if if there's a log out condition as well. So that's really that that's
a guest account. That's everything you need. Now there is another way around this potentially
if you don't have the space or the power for ram disk and back power mean compute power. Like you
just don't have enough ram for this to work. On some small devices like Raspberry Pi you might just
might not be reasonable to say oh I'm going to sacrifice like half of my ram for this temporary space
that people may or may not use and then may or may not use very often. So maybe that doesn't make
sense. You can do all of this with system D as well or whatever in its system you happen to be using.
I was doing this on a fedora system so I just used system D. In that case you can create your own
customs service. This service is what it could be called like kiosk.service for example. And the
unit file for that would be square bracket unit close square bracket description equals kiosk
clean up square bracket service close square bracket type equals one shot exact start equals slash
USR slash local slash bin slash kiosk dash cleanup dot s h that doesn't exist yet will create
it in a moment. Square bracket install close square bracket wanted by equals power off dot target
reboot dot target and multi dash user dot target. So what this service file does is it gets triggered
every time a power off or a reboot or a startup action or event rather is received or triggered by
system D. So that covers everything but log out log out is still being handled by gdm. But because
this isn't in a ram disk in this example. Instead we're listening to it for a power off from anywhere.
It's a system wide power off. Okay. Well it will trigger our kiosk cleanup script which we haven't written yet.
A reboot same thing and even a startup startup event. And I'm doing the startup event to mitigate
against power outages unintentional power outages. If if the power fails and your computer gets shut down
once again that wasn't a power off signal that wasn't a reboot signal. That's just there's no more
power. It goes away. So in that event in that case you need to catch the fact that we're starting
back up and there may still be data hidden away in a user account that shouldn't be there. Again that's
a little bit of a security hole and makes me not super confident in that particular work around.
I'd much rather I think go with the ram disk. Technically speaking there's not a whole lot
anyone can do as long as the disk if you're using full disk encryption then that data should
still be locked away until a startup sequence begins. At which point the data is then removed.
Is there a millisecond in there where the data still exists that could theoretically be sort of
manipulated or exploited? Probably haven't tested it but definitely the ram disk I think sounds like
the the more secure way to do this. But in this context I think where there has been no guarantee
of absolute just airtight privacy. I think this is more of a more of a solution for like casual
like look you don't I don't want all of your random search histories and your caches and
downloads and save documents on my computer so it's going to be removed anytime I start up.
I think that this works for those use cases. If this is an environment where absolute privacy and
data security is required I don't think I would be using system D for that I'd be using the ram
disk at the very least. So anyway that's the caveat there. The point is the system D power off
target reboot target and multi-user target ensures that a removal script is triggered when someone
shuts down or reboots or starts up the computer. The script that I used for this I saved to user
user local bin and I called it kiosk-cleanup.sh. It's a little bit of a repeat I guess
of the gdmscript but it has to be has to be a little bit more robust so or a little bit more
complete really. So I do an rm-rf of home library guest and then I make a directory called
slash home slash library guest and then I chone dash capital r library guest colon library guest
slash home slash library guest. So I'm recreating I'm removing and then recreating an empty library
guest home. The reason I'm doing that is because there's nothing here there's nothing in this process
to restore what I've removed in this case unlike where the the gdm thing manages the session
and sets up the environment. There's that's not what there's nothing to do that here so I'm recreating
it myself. I don't have to create all the sub-director's gdm does that for me but or I guess the
scale subsystem does that for me but certainly removing and then recreating and then restoring the
permissions is important. So grant the script itself permission to run pseudo-chmod plus x slash
user local bin kiosk-cleanup.sh and now the library guest user data is erased after a log out by
gdm a reboot a shutdown or a startup by system d and again that's only necessary if you just
don't if you don't have the capacity to do it as a ramdesk. If you do a ramdesk you can just
stop after gdm and creating the ramdesk in the user really really nice. As I say there's data
privacy concerns here like if you're doing this for for the general public or even for just
friends of yours it's obviously really important to make it known to people I mean I don't know if
they care but I mean I think it's think it's our obligation as just admins to make it known to people
that the scope of what you're assuring them or what you're guaranteeing them. So if it's on a
ramdesk and gdm as you're doing the erasure after a log out you probably have a pretty good cause
just to say that you know that yes their data is erased upon log out. I don't think the reboot
and shutdown power off really matters or that that'll go away so you don't have to I don't think
mention that but the log out thing assures them that their data will be removed but it's it's
fair warning as well like hey look don't keep your stuff here without putting it on the cloud
or on a thumb drive or something because it is going to be erased. They need to know that
people need to know what they're what they're signing up for when they're signing in to a computer.
I think it's also sort of our responsibility to admit that glitches and exceptions could occur.
I mean especially if you're using the system D work around in that case I think it would be
sort of I think it would be the right thing to say is that you know like while we're doing
our best to ensure that all data is removed you know it's not entirely impossible for the data to be
cashed for you know less than 24 hours and in some instances something like that so that
people know that there's a vague chance that data could be preserved beyond the expectation
and if they're not comfortable with that and that's that's perfectly all right then they know
what not to do on your on this system obviously telling people or reminding people that they're
on a public computer on a public network is probably a good thing as well so without going into all
of the security measures we would need to do to keep people somewhat protected from malicious
actors on all public computers I I think in terms of just getting that data erased that's what
I've come up with a GDM ram disk or system D in a pinch I hope this was useful uh give it a go try
it out see if it's a useful thing for your laptop a guest account I find it really kind of a nice
to have it's not necessary because realistically not that many people ask to use computers these days
again a pinch they have their mobile phones so it doesn't really matter but it's kind of a nice to
have it's kind of cool so um of course for me I also have to switch the keyboard over to from
divorce act to courties so that's a thing as well I haven't really looked into how to make that
automated on my guest account I'm not that concerned about it because again not that many people
ask but it's still a fun project and certainly it's very useful for a public installation so
hopefully this is uh informed you or giving you some ideas if you ever have to come up with something
like that for your library or a museum or or somewhere that you work where you want to provide
public computing services to people thanks for listening talk to you next time
You have been listening to the Hacker Public Radio podcast, at hackerpublicradio.org.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording a podcast, then visit the HPR site to find out how easy it really is.
Hosting for HPR has been kindly provided by anhonesthost.com, the Internet Archive, rsync.net, and the HPR Community Content Delivery Network.
Unless otherwise stated, today's show is released under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.