Can I create a local only guest account?

Question

Is it possible to create a "guest" account in Linux? by "guest" account I mean an account that does not require a password to log in graphically.

I want this account for when people come over and are like "can I use your computer to check my email". Then I don't have to worry about them snooping my stuff.

I realize that some of this may require doing stuff specific to the login manager, since I wouldn't be surprised that this is a common problem, it'd be best to include instructions for xdm, kdm, and gdm and any other login managers that I haven't listed.

Solution 1

Yes, you can create a password-less account.

sudo useradd -m guest
sudo passwd -d guest

Important, though, it to make sure no network daemons like sshd will allow access to password-less accounts. That's usually default, but it's good to check. Make sure PermitEmptyPasswords is no/false in /etc/ssh/sshd_config or just try and ssh into guest and see if it allows you. There may be other daemons like Samba you should check for as well. If you want to restrict the user from accessing your local files, you can either go to great lengths like setting up a chroot with pam_chroot.so and the like, or instead, just restrict your data to you. Make use your home directory does not allow the "other" class to read your files and lock down any other locations you think you need to.

Solution 2

Sorry, I don't actually have a way to do what you're asking, but I think this answer will be helpful nonetheless.

What do you mean by “does not have shell access”: do you mean that the user must only be able to use a few applications (e.g. a web browser and a mail client)? If so, you need to make sure that the applications won't inadvertently allow the user to run arbitrary commands. That's hard to ensure in practice.

This is generally known as a kiosk setup. There are many Linux kiosk projects, but most aim at making a kiosk machine, not a kiosk account that must coexist with other accounts.

A kiosk account is harder to secure. I think you'd have to use something like SELinux or a virtualization technology to prevent the guest from snooping on publicly-readable files (or else manually tighten all permissions, but there are things that are cumbersome to protect, such as the user list (/etc/passwd)). I don't know of any project that offers this out of the box.

It should be relatively easy to set up a guest virtual machine with VirtualBox. VirtualBox has a kiosk mode where you can disable all VM controls in the GUI. Then you can run that VM as the sole application on an X server. Make sure to lock all other consoles when you're not using them, and voilà, you have a kiosk vt. Of course, the VM shouldn't be sharing any folder and its networking should be limited to outgoing NATted connections.

Inside the VM, you can run a kiosk setup, but that's not even necessary. Just take a snapshot of the VM and discard that snapshot after a guest has been using it. If you need to perform upgrades, start from the snapshot, upgrade, then make a new snapshot.

Coming back to having a guest user (and not addressing guest restrictions here), on the authentication side, there's nothing special to set up in each login manager. The whole point of PAM is to be independent of the session type. Make a user who can't log in normally, and allow that user to log in through a pam_userdb line for the login method(s) you want to authorize (something like auth sufficient pam_userdb.so db=/etc/passwd_guest in /etc/pam.d/?dm, with /etc/passwd_guest containing guest::9999:9999:/home/guest:/bin/sh and /etc/passwd containing guest:x:9999:9999:/home/guest:/bin/false).

Comments

[xenoterracide]

I'm just gonna remove the restrictions part, 'cause it's not that relevant to the actual problem, now that I think about it... which makes all your kiosk part of the answer unnecessary.

[xenoterracide]

tried it, I can't su - to guest, which means guest can't log in, which is not what I'm trying to accomplish.

[penguin359]

Please do more testing or ask for help before voting a perfectly good answer down. Yes, su - guest will fail when run from an X Terminal or a remote shell session. That's because in some file like /etc/pam.d/common-auth there is an argument to pam_unix.so called nullok_secure That means a null or password-less login is ok only as long as it's on a secure terminal. Some random X Terminal or remote shell is not considered secure, but your trusty X/Gnome/KDE Display Manager is considered trusted as well as a local Text Console. Please try to login via one of those and be happy.

[penguin359]

You can change nullok_secure to nullok if you really want to always allow guest to login through any old terminal using su - guest or similar, but I recommend against it. It sounds like you really only need guest to login via the nice little Graphical Login screen on your desktop. I tested my exact solution and it did work on a relatively stock and freshly installed Ubuntu 10.10. Yes, su - guest did fail when I did it from an X Terminal, but worked from a Text Console.

[penguin359]

@xeno The official docs on Down Voting: "What are the alternatives to downvoting? The upvote privilege comes first because that's what you should focus on: pushing great content to the top. Downvoting should be reserved for extreme cases. It's not meant as a substitute for communication and editing."

[xenoterracide]

@penguin359, I also tried it in kdm, and kdm didn't like it either. Yes I'm aware that a lot of this might be pam. You might not be aware of this but not everyone uses Ubuntu, and I really hate people that assume someone is using Ubuntu on Unix SE. If my question were about or even on Ubuntu, I would ask on AU. Also per official docs, I'd love to see a link to that. Downvoting is good for answers that aren't good or aren't entirely accurate. So though your answer might work on Ubuntu, it doesn't work in other places. I can change my vote later. I'll play with this tonight after sleep and doc.

[penguin359]

@xeno I absolutely did not assume you used Ubuntu, I did absolutely assume you use Linux and hence use PAM for authentication. That why I phrased it like "in some file like" and not _"the file" because the file might be a different name that has the pam_unix.so module. I have used Fedora, Debian, Gentoo, Ubuntu, and other distros, they all name the file differently, but they all use pam_unix.so and have the same nullok/nullok_secure options. Maybe your problem is that you don't even have nullok set for pam_unix.so. My answer does work on other distros, but you need to RTFM and understand

[penguin359]

Regardless, the docs on Vote Down clearly state that this is not a case for Vote Down which is "reserved for extreme cases." You are just not attempting to communicate when something doesn't work.

[penguin359]

After re-reading my original answer, there was nothing Ubuntu specific in it. It applies equally to Fedora, RHL, Gentoo, and Debian as well. Some more obscure distro might place the sshd_config file elsewhere, but I'd expect you to be able to find it or ask for help. A quick locate sshd_config should locate it. My first comment assumed nullok_secure was enabled by default which might be Ubuntu specific, but hopefully that would encourage one to look at their PAM config and read the man page for pam_unix or at least ask a question. A quick grep -r pam_unix /etc/pam.* should help.