Guest Account in Slackware?

13stein.j · 06-10-2013, 01:25 PM

Quote:

Originally Posted by BlackRider

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.

What does Knoppix have to do with it?

qweasd · 06-10-2013, 02:22 PM

Quote:

Originally Posted by Richard Cranium

I don't see how installing gdm would do any of those things.

You are right... Guest session is a Ubuntu native.

Anyways, some great advice was given in this thread, but me personally would not create a guest/nopass account on a networked UNIX box, not for any reason. If you use KDM, you have a better option. There is a no-pass login checkbox in systemsettings, so you could create a guest user with a strong password, but have it skipped during the graphical login.

BlackRider · 06-10-2013, 03:42 PM

Quote:

Originally Posted by 13stein.j

What does Knoppix have to do with it?

I think you have not understood me.

I have a laptop with a frugal install of Knoppix. That means there is a partition with Knoppix in it, and I have tricked the computer to think it is a CD (so to speak), so it boots Knoppix from there as if it was a CD.

It is a tweaked version of Knoppix that loads some custom stuff from an encrypted partition at boot. That means that, when you boot Knoppix, it asks you if you want to boot "tweaked" or "regular". When I want to use the computer, I boot "tweaked" and get into my system using the password. If I wanted to lend the computer, a guest would boot "regular", which is like booting a regular Knoppix DVD, just faster. Whatever a guest does in a regular Knoppix disappears when he shuts down. Whatever I do in my tweaked version remains with some limitations.

So, a suggestion other than create a guest account would be to create this setup OR a OS only for the guests (which could be a regular Knoppix or Live system, as whatever is done during the live session is not conserved). I say again, this setup has implications to consider carefully, but could be a good idea in some scenarios.

13stein.j · 06-12-2013, 12:56 PM

Quote:

Originally Posted by Z038

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.

Code:

# chmod +x /etc/rc.d/rc.autofs
# /etc/rc.d/rc.autofs start

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.

Code:

/misc   /etc/auto.misc
/-      /etc/auto.direct   --timeout=60

Code:

# /etc/rc.d/rc.autofs restart

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.

HTH, have fun.

Startx doesn't work, but I think I found out the fix, make all the folders inside tmpfs, and restrict access to the /home/guest folder, and the .xxx folders within, am I correct? And out of curiosity, what does the :/guest do in the auto.direct file?

Z038 · 06-12-2013, 03:53 PM

startx worked for me using both KDE and XFCE desktop environments. I didn't have to create any folders in the guest home directory ahead of time. In fact, anything you create in /home/guest before starting automount will not be accessible when the /guest temporary filesystem gets mounted on top of it.

What error do you get when you issue startx?

/etc/auto.direct is an automounter map file. For the full description of the format and options, refer to the man page for autofs (e.g., "man autofs"). You might also check out the man pages for automount and auto.master.

The format of a map file is:

Code:

key    [options]   location

Our /etc/auto.direct map file specifies:

Code:

/home/guest      -fstype=tmpfs,rw       :/guest

It may be more clear if I explain these fields in reverse.

The location field is sometimes called a map name. :/guest is the map name that gets mounted on the key (mount-point). Usually it is a device name (e.g., /dev/hda1) or a network filesystem (NFS) share (e.g., server1.example.com:/pub/linux). The colon : in front of /guest is the Sun map format escape character that is required for any map name or location that starts with a /.

-fstype=tmpfs,rw are the options. They are optional and not required for many map entries, but they are required in our case because we want /guest, which does not already exist anywhere, to be a temporary filesystem that gets created dynamically.

/home/guest is the key, or mount-point, that automount monitors. Whenever the mount-point is referenced, automount mounts /guest on it. Since we specified a filesystem type in the options, automount includes that when it issues the mount command to mount /guest on /home/guest. The mount actually creates the /guest temporary filesystem.

13stein.j · 06-12-2013, 04:27 PM

Quote:

Originally Posted by Z038

startx worked for me using both KDE and XFCE desktop environments. I didn't have to create any folders in the guest home directory ahead of time. In fact, anything you create in /home/guest before starting automount will not be accessible when the /guest temporary filesystem gets mounted on top of it.

What error do you get when you issue startx?

/etc/auto.direct is an automounter map file. For the full description of the format and options, refer to the man page for autofs (e.g., "man autofs"). You might also check out the man pages for automount and auto.master.

The format of a map file is:

Code:

key    [options]   location

Our /etc/auto.direct map file specifies:

Code:

/home/guest      -fstype=tmpfs,rw       :/guest

It may be more clear if I explain these fields in reverse.

The location field is sometimes called a map name. :/guest is the map name that gets mounted on the key (mount-point). Usually it is a device name (e.g., /dev/hda1) or a network filesystem (NFS) share (e.g., server1.example.com:/pub/linux). The colon : in front of /guest is the Sun map format escape character that is required for any map name or location that starts with a /.

-fstype=tmpfs,rw are the options. They are optional and not required for many map entries, but they are required in our case because we want /guest, which does not already exist anywhere, to be a temporary filesystem that gets created dynamically.

/home/guest is the key, or mount-point, that automount monitors. Whenever the mount-point is referenced, automount mounts /guest on it. Since we specified a filesystem type in the options, automount includes that when it issues the mount command to mount /guest on /home/guest. The mount actually creates the /guest temporary filesystem.

I use xfce and There are timeouts in locking .serverauth.3482 and .Xauthority

Z038 · 06-12-2013, 05:31 PM

Sounds like a file permissions problem. When you are in your guest home directory, enter "ls -al" and post the results.

13stein.j · 06-14-2013, 09:20 PM

Quote:

Originally Posted by Z038

Sounds like a file permissions problem. When you are in your guest home directory, enter "ls -al" and post the results.

Sorry to have bothered you, the problem was that I had to login after reviving the password, creating screen.rc, and then use startx, creating the other folders and files, the make it a tmpfs. Thank you for your large help, but a new question comes up, how to restrict access to installing programs, and other possibly harmful commands to be used?

Z038 · 06-14-2013, 10:46 PM

I think that all of the commands that could be harmful to the system require root authority, provided you don't have system-owned or otherwise critical files and directories with world write permission.

I'm the only user of my systems, so I've never had to consider restricting access beyond ensuring proper file and directory permissions.

You might want to start a separate thread on the access restrictions.

T3slider · 06-14-2013, 11:15 PM

You may want to mount the guest tmpfs, as well as /tmp and /var/tmp (and probably /dev/shm), as noexec (and maybe nosuid, but maybe not) to prevent users from being able to run binaries from those filesystems. This way the only binaries that can be run exist on filesystems without guest write access (which prevents most privilege escalation attempts). If you do need to run binaries from a user-writable directory this may not be feasible.

Z038 · 06-14-2013, 11:40 PM

T3slider, I believe the OP wants his guest account to be useable for normal desktop and internet activities by visiting friends and neighbors. Is it possible to run a desktop environment in a filesystem that is mounted noexec?

13stein.j · 06-15-2013, 07:28 AM

Quote:

Originally Posted by T3slider

You may want to mount the guest tmpfs, as well as /tmp and /var/tmp (and probably /dev/shm), as noexec (and maybe nosuid, but maybe not) to prevent users from being able to run binaries from those filesystems. This way the only binaries that can be run exist on filesystems without guest write access (which prevents most privilege escalation attempts). If you do need to run binaries from a user-writable directory this may not be feasible.

Not exactly, but Z038 is right, I will start a new thread called "restricting commands for other users", and another, which is completely not related called "why can't sudo do some su commands".