SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Nope, that stays. whoami returns the name of the user who ran it. The only thing you'd have to change is "guest" to match the name of your guest user (and if that user is actually named 'guest', then you don't have to do anything).
I played around and got automount to mount the /home/guest directory onto a temporary filesystem called /guest. The tmpfs mount occurs when the /home/guest directory is referenced. Automount will create the /guest directory in the temporary filesystem for you. When the filesystem is unreferenced for --timeout seconds, automount will unmount it, the temporary filesystem will be destroyed, and all the files in it will disappear.
Do 1 through 5 and 9 and 10 as root:
1) Create the guest user account using the Slackware adduser script, or the useradd command. Specify or default to /home/guest as the home directory. Give the account a password.
2) Remove the "x" after the username in /etc/passwd as I explained previously in post #2. This will allow "guest" to logon without specifying a password.
3) Edit the /etc/auto.master file. After the existing line that says "/misc /etc/auto.misc", add a new line "/- /etc/auto.direct" It should now look like this:
Code:
/misc /etc/auto.misc
/- /etc/auto.direct
4) Create the /etc/auto.direct file using an editor of your choice, or echo. Add this line:
Code:
/home/guest -fstype=tmpfs,rw :/guest
5) If /etc/rc.d/rc.autofs is not executable, make it so, then start it. Once marked executable, it will be automatically started during any subsequent boot.
6) Start a new text console (e.g., CTRL+ALT+F2) and login as guest. You should not be prompted for a password.
7) Test to make sure your home is really in a temporary file system by issuing the mount command with no operands, or the df command. The mount command output should include a line like this at the bottom:
Code:
/guest on /home/guest type tmpfs (rw)
8) Create some files in guest's home directory and list them.
Code:
$ touch a.b
$ touch 1.2
$ ls -al
total 4
drwxrwxrwt 2 root root 80 Jun 9 00:30 ./
drwxr-xr-x 20 root root 4096 Jun 8 15:54 ../
-rw-r--r-- 1 guest users 0 Jun 9 00:30 1.2
-rw-r--r-- 1 guest users 0 Jun 9 00:30 a.b
9) Log out from guest. The default timeout value that automount uses to unmount the filesystem is 600 seconds (10 minutes). Wait 10 minutes, then from another account, issue the mount or df command again to verify that the /guest tmpfs is gone. You can specify a different timeout if you like. To set a timeout of 1 minute, for example, add --timeout=60 at the end of the line you added to /etc/auto.master, and don't forget to restart autofs afterwards.
10) After the /guest tmpfs has been dismounted, issue "ls -al /home/guest" as root. You should not see the a.b and 1.2 files that you created when you were logged in as guest. They were destroyed when the temporary file system was unmounted by automount. You might see a file called .screenrc, as it is copied to a user's home directory when the account is created. If you logged in to guest before setting up automount, there could be other files there too. But nothing that was created when guest was signed in with the automounted tmpfs will be found.
Note: I've never used automount before today, so I can't say for sure that there won't be any glitches. But I played with it for awhile, and it all worked as I've described.
Didn't Ubuntu have a guest session available from the gdm login screen? Is that a gnome feature or a Ubuntu feature? If the former, it may be the best to just install gdm. All this business with making guest/nopass accounts, automounting, and writing rm -rf scripts promises nothing but trouble down the road. If it was me, I'd either obtain a complete solution such as they have in Ubuntu, or put up a dedicated machine with auto-login.
The autofs is a neat idea. I might have to try this idea myself.
I already use autofs for my home directory, cdroms and usb thumb drives.
Here's a quick suid program I wrote to signal the automount daemon to release any unused mounts immediately rather than wait for the timeout. I use it to trigger the unmount of cdroms and usb sticks but it might be useful for triggering the unmount in the .bash_logout rather than relying on the timeout.
A .bash_logout along the lines of the following might do the job.
First I created a 'guest' user with home /home/guest.
Then inspired by Z038's autofs idea I added an entry to my existing auto.u indirect map (where my existing user home dirs are mounted)
Code:
root@ws1:~# cat /etc/auto.master
#
# auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
/u /etc/auto.u
/misc /etc/auto.misc
root@ws1:~# cat /etc/auto.u
#
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage
guest -fstype=tmpfs,mode=700,uid=guest,gid=users,rw guestfs
* -rw :/srv/crypt/home/&
root@ws1:~#
note: I've added some permissions to the tmpfs as the defaults aren't ideal.
I then did a usermod -d /u/guest guest to let the guest user use the new automounted home directory.
Then I added /home/guest/.bash_logout using my 'release' program as described above:
Code:
cd /
exec /usr/local/bin/release
And then added something to the top of /etc/profile to populate the /u/guest directory
Code:
if [ "$USER" = 'guest' -a ! -d ~/.guest-populated ]; then
mkdir ~/.guest-populated && cp -aT /home/guest ~
exec bash -l
fi
And then to add support for GUI logins using xdm:
Add the directory population code to the top of /etc/X11/xdm/Xsession:
Code:
# if 'guest' account populate home directory
if [ "$USER" = 'guest' -a ! -d ~/.guest-populated ]; then
mkdir ~/.guest-populated && cp -aT /home/guest ~
fi
And finally, add a call to /usr/local/bin/release to /etc/X11/xdm/Xreset to perform the unmount on logout.
(edit: actually, this bit doesn't seem to work from either Xreset or TakeConsole. I had to move the call to release into
Xsetup instead. No idea why, couldn't see anything holding /u/guest open when I did a fuser on it.)
It's all very hackish, but as a proof of concept seems to work
Last edited by GazL; 06-09-2013 at 02:14 PM.
Reason: slightly less hackish /etc/profile modification
Sounds promising, but can restarting autofs be done about 5 seconds after guest logout and data destruction? Automatically?
It's not necessary. You only need to restart autofs if it is already running and you make a change to the /etc/auto.master file or the /etc/auto.direct file. In step 9, I added the --timeout value to override the default of 10 minutes, and that is why autofs had to be restarted.
If you just set it up the way I described, but add the --timeout=60 (or 5, if you want it to be that fast) back in step 3, then you'll be good to go. It's all 100% automated after the initial setup. You won't have to mess with it again.
Distribution: Linux Mint 15/Ubuntu 13.10/Debian 7/SUSE 11.x/openSUSE 12.3/RHEL 6.4/Fedora 18/Slackware, and 5 more
Posts: 111
Original Poster
Rep:
Quote:
Originally Posted by Z038
It's not necessary. You only need to restart autofs if it is already running and you make a change to the /etc/auto.master file or the /etc/auto.direct file. In step 9, I added the --timeout value to override the default of 10 minutes, and that is why autofs had to be restarted.
If you just set it up the way I described, but add the --timeout=60 (or 5, if you want it to be that fast) back in step 3, then you'll be good to go. It's all 100% automated after the initial setup. You won't have to mess with it again.
One last thing-- will the data be cleared 5 seconds after the graphical logout our the console logout? I use LXDE, and I'm not sure if this is supposed to happen or not, but I login, run startx to get to the graphical desktop, but when logging out of the graphical, you still have to logout of the text console. Is that supposed to happen, and even if it isn't, which is an entirely different forum post, when will the data be cleared? And will the data be cleared at shutdown, if the guest decides to shutdown instead of logout?
If --timeout=5 is set in the /etc/auto.master file, then automount will dismount the temporary filesystem 5 seconds after it is no longer in use. If guest logs out of the graphical environment to the text console, he will still be in his home directory, so the filesystem will still be in use. In fact, even if he leaves his home directory, say to go to /etc, his bash interactive shell is still using the temporary filesystem, so it won't go away. Bottom line, it will remain mounted and will continue to exist as long as he is logged in. It won't be unmounted and deleted until he logs out. Of course, a system shutdown will also unmount and delete guest's temporary filesystem. It only exists in memory, and it won't survive a shutdown.
Hard drives are so huge these days, there is no reason you can't have two, three, ten or more installs of slackware on a disk.
Setup one of those to be the sacrificial lamb. Every so often you can use dd to take one of the pristine installs and overwrite the install that the guests use and muck up.
If you are going to use a OS just for guests, I would recommend using a Live system with a frugal install. That is good because initial state of the system is recovered on reboot. This has its own bunch of problems, but it is another option.
My laptop has a frugal install of Knoppix with heavy tweakings to load customizations from an encrypted partition. This way, if I have to lend the computer to someone for a minute, I just can tell then to skip the security protocol when asked to during boot, thus launching regular Knoppix. My own "system" remains encrypted and ready for use at reroot, and can be accessed only with the password.
Distribution: Linux Mint 15/Ubuntu 13.10/Debian 7/SUSE 11.x/openSUSE 12.3/RHEL 6.4/Fedora 18/Slackware, and 5 more
Posts: 111
Original Poster
Rep:
Quote:
Originally Posted by BlackRider
If you are going to use a OS just for guests, I would recommend using a Live system with a frugal install. That is good because initial state of the system is recovered on reboot. This has its own bunch of problems, but it is another option.
My laptop has a frugal install of Knoppix with heavy tweakings to load customizations from an encrypted partition. This way, if I have to lend the computer to someone for a minute, I just can tell then to skip the security protocol when asked to during boot, thus launching regular Knoppix. My own "system" remains encrypted and ready for use at reroot, and can be accessed only with the password.
The idea is that you can use this system for yourself (with the password) or give it to a guest (who, without the password, would have to boot the regular Knoppix).
It is not great, but it is an Ok solution if the need arises and you understand the consequences.
You could also just use a frugal Live system for guests and a regular operating system for yourself, depending on many factors.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.