Setting permissions in Vector Classic for a public multi-user system

[Colonel Panic]

Hi again. I've recently had the opportunity to install 6.0 KDE Classic on a computer in my local community centre, with the intention that it can be used freely by any of the various people who come to the Centre to browse the Internet, send e-mails, use social networking sites such as Facebook and myspace, write letters and edit documents etc.

I'd like to be able to set a user account so that people using the system can't do any damage to the system files, whether accidentally or otherwise (Windows XP can get in a right state sometimes on the machines there). Is there a simple rule of thumb which governs how to set up the permissions in user accounts in situations like this?

Thanks in advance,

Colonel Panic.

[bigpaws]

Linux us already a multiuser system and designed as you are asking
about. A user should be creating files with the permissions of
Owner - RWX Group - R-- Other ---

Make a new user or check your current users permissions.

Now to explain what you are thinking vs what really happens.

In Windows a progam has the settings in one file and users inherit
those settings (Most of the time). In linux that is what the .<file name, or directory>
is for. Example Enemy Territory in Windows the settings are system wide, where as
when using Linux the settings are under the user in .et . A normal user if the system
is setup properly can not affect the system settings. Which was done by design.

I hope that makes things a little more clear.

Bigpaws

[Colonel Panic]

Thanks for replying. I am aware that Vector's a multiuser system; what I was wondering though was that if I create a new user which belongs to all the groups (plugdev. disk, cdrom etc.), as I'm intending to do, do I have to do anything else to secure the system and prevent ordinary users from being able to, for example, delete key system files? Or to prohibit a casual user from being able to download and install unauthorised software?

I could of course experiment with my system, i.e. try and mess things up from a user account, but as I hope you can appreciate I don't really want to succeed at that so I'm unlikely to attempt it; it took me long enough to get Vector Standard set up the way I like it with all my apps configured etc.

From reading your post it seems that I don't need to do anything extra, but I'd be grateful if you wouild confirm this for me.

[toothandnail]

Thanks for replying. I am aware that Vector's a multiuser system; what I was wondering though was if I create a new user with which belongs to all the groups (plugdev. disk, cdrom etc.), do I have to do anything else to secure the system from being able to, for example, delete key system files? Or to prohibit a casual user from being able to download and install unauthorised software?

A normal user (who belongs to all the normal groups) will not be able to delete anything out of the home directory created when you create the user. Downloading files is not very easy to prevent, but they will only be able to be saved to the user's home directory. Installing software is also not something that is easy to completely prevent, but a normal user would only be able to install to the home directory as well, which means that doing so should not affect anything else in the system. Even if they install something that could damage the system, unless they can gain root access, the system should prevent them from doing any damage.

So far as I can see, the main problem you would face is that people will download things and leave them lying around in the user home you have created, so you'll eventually end up with a fairly messy situation.

I wonder if it would be possible to have the user removed when they log off, and recreated when the system is next started? That would allow a frequent cleanout, and also make sure that the user's privacy is protected. I think it should be possible with some scripts, but I'd have to think a bit about exactly how to do it. Someone else may have a better idea.

I know there are some distros which come with a 'Kiosk' mode which esentially provides access without allowing things to get to messed up. There was a variant of Zenwalk that was created that way - done by a guy in Malasia, if I remember correctly. Maybe a bit of googling for 'kiosk-mode linux' would get you some good answers.

The other thing that would be useful in the situation you're trying to create would be allowing users to copy files they've downloaded (or copies of email) to things like pen drives. You would probably need to look at modifying the standard menus to remove quite a lot of applications, but it should all be doable.

An interesting project....

I could of course experiment with my system, i.e. try and mess things up from a user account, but as I hope you can appreciate I don't really want to succeed at that.

Urk. That doesn't sound like a very good idea, at least not unless you want to reinstall. I guess you could create a new user for your own system and experiment with that, since changes you make to that user should not affect your normal user account at all. That way you can at least check that you have the correct restrictions in place.

It might also be possible to create a specifically limited user account - I have seen a couple of things that effectively create a chroot jail for limited user access. While most of those are intended for online, remote use, it should be possible to do for a local user as well. I'll see if I can find some references to the software used for that purpose and get back to you.

Paul.

[nightflier]

If you want the "public user" profile to be reset to defaults upon reboot, it should be possible with a startup script.

That sounds like an interesting experiment, I'll do some testing on one of my machines.

[Colonel Panic]

Thanks for both your posts. I think I've probably been worrying unnecessarily about downloaded apps - not many of our users would know how to do it (or how to build them afterwards).

Allowing the "public user" profile to be reset to defaults upon reboot sounds like an excellent idea, I wish I'd thought of it myself.

toothandnail; a "chroot jail" account sounds to me like overkill in the first instance but it'd still be useful to know about it as a failsafe option; if it's not a big problem to fish out the details, I'd be interested to learn about it. Thanks anyway.

Cheers and Happy Easter,

CP .

[retired1af]

I wonder if it would be possible to have the user removed when they log off, and recreated when the system is next started? That would allow a frequent cleanout, and also make sure that the user's privacy is protected. I think it should be possible with some scripts, but I'd have to think a bit about exactly how to do it. Someone else may have a better idea.

I've never thought of that, and it brings up an interesting idea. I don't see why it wouldn't work. You should be able to set the script to run before it goes to bootlevel 4 and then log into the "user" automatically. Although I could see one hiccup. If someone was working on something and for some reason the system got shut down (power issues, kicked plug, etc.), they would loose everything because the script would wipe it out.

Perhaps a multiboot option in LILO or GRUB? One that wipes the user and resets, and a normal one?

[nightflier]

Deleting and re-creating the user home folder on boot was easy enough. I just tarred it into a file, added commands to rc.local for removing the user home and then extract the tar file.

If you want a recovery option, you can have rc.local re-name old user home instead of deleting it. Maybe keep a few levels of it so you could go back more than one instance. Could also be useful for reviewing what users are doing.

While I was having some fun with the user profile (removing items from panel, disabling desktop click action, making Firefox autostart...), I found that KDE has a "Kiosk mode": http://techbase.kde.org/KDE_System_Administration/Kiosk/Introduction

[toothandnail]

Deleting and re-creating the user home folder on boot was easy enough. I just tarred it into a file, added commands to rc.local for removing the user home and then extract the tar file.

If you want a recovery option, you can have rc.local re-name old user home instead of deleting it. Maybe keep a few levels of it so you could go back more than one instance. Could also be useful for reviewing what users are doing.

It shouldn't be hard to set up x (say 5 generations) and remove the oldest on startup. That should provide enough fallback to ensure things can be recovered, and to keep some track of what users have been doing.

While I was having some fun with the user profile (removing items from panel, disabling desktop click action, making Firefox autostart...), I found that KDE has a "Kiosk mode": http://techbase.kde.org/KDE_System_Administration/Kiosk/Introduction

Good find! That looks ideal to set limited user access and keep things tidy. I didn't realise that KDE had a Kiosk mode option.

Paul.

[nightflier]

This was pretty easy to set up. My code may not be elegant, but since I went ahead and created it, here is what I did (all done as root):

Create the tar file:

Code:

tar -cvf /root/publicuser-home.tar /home/publicuser/

Add startup commands to /etc/rc.d/rc.local:

Code:

rm -rf /home/publicuser5
mv /home/publicuser4 /home/publicuser5
mv /home/publicuser3 /home/publicuser4
mv /home/publicuser2 /home/publicuser3
mv /home/publicuser1 /home/publicuser2
mv /home/publicuser /home/publicuser1
tar -xf /root/publicuser-home.tar -C /

[Colonel Panic]

Thanks for the further replies (and the scripts nightflier)! I also didn't know KDE had a kiosk mode.

I'll probably print this thread off at some point to read away from the computer.

Cheers and happy Easter everyone,

Colonel Panic .

[Colonel Panic]

A quick update; I ve now done a practice run on my own machine with two different users, one in normal user mode and the other in kiosk mode (which requires a separate utility called kiosktool to be downloaded and installed) and it seems to work fine, except that I'm unable to reboot the system or shut it down in either mode. I have to press Ctrl-Alt-Delete to get out of either mode.

Can anyone tell me if there's a simple solution to this, please?

Thanks in advance,

CP .

[nightflier]

I think that requiring CtrlAltDel for shutdown is actually a good idea.
Is there no log out optioin on menu, or does it just not work?

[Colonel Panic]

Thanks for replying nightflier. I'm not in Vector at the moment so I can't check it right now, but from memory there was an option on the menu and it didn't work, and nor did typing "halt" at the terminal (it was interpreted as a bash command or something and rejected).

I'll let you know when I'm back in Vector. Thanks for your interest anyway.

CP .

[Colonel Panic]

A quick update; logout does work but is the only option on the menu and just returns you to the command line. From there, neither reboot nor halt work.

Typing halt or reboot in the "KDE Run" box gave the message; "Sorry. "Could not run the specified command."

So Ctrl-Alt-Delete is the one option which works. Thanks for your interest anyway,

CP .