I have to make a couple disclaimers here -
- * It has been suggested that I fork Puppy and produce a multi-user build along with other members of the community who are keen on it. This I will NOT do. I just plain have too many projects to support already. I will support multi-user functionality in Grafpup, and I am willing to share the work that I have done with anyone who wants to duplicate it or create something similar.
* The methods I am using are in some cases experimental, and are definately not for a new user to try and set up. While I have security in mind there is even a chance that occasionally one of my changes might make a system less secure than if it were running solely as root, although I doubt that is actually the case.
* Encrypted save files are not the same thing as a multiple user system. They are a fantastic feature and can offer some of the functionality, but a true multiple user setup is a completely different animal.
* I will not respond to criticism of the nature that Puppy does not need multi-user support, or suggesting that this project is not worthwhile. Don't bother, I think there are enough people who want to see a multi-user Puppy system, and I will work to have your comments removed from this thread if you troll here. I'm not here to debate it, I'm here to assist others in implementing it if they want to try.
For now I will describe a rough overview of the changes that need to be made (if you are following my methods) to get a setup off the ground. I will provide more details as the thread progresses, and probably a good deal of code. There is a chance I may offer runnable packages or patches against Puppy, but I make no gaurantee to that effect.
The main things preventing Puppy from being truly multi-user are :
- * Most Puppy configuration and startup scripts reference or create files in /root or /etc rather than in $HOME.
* The directory /tmp is not writable by anyone other than root.
* Certain dev files also have restrictive permissions.
* The X server must be suid root to run X with another user.
* Tinylogin must be suid root to allow normal user to use su.
A quick example would be the setting for which WindowManager to start:
Code: Select all
CURRENTWM=`cat /etc/windowmanager`
Code: Select all
#0.9.9 enables to start a specific w.m. from commandline...
if [ $1 ];then
echo -n "$1" > /etc/windowmanager
#note, $HOME/.xinitrc uses this file.
fi
Code: Select all
#0.9.9 enables to start a specific w.m. from commandline...
if [ $1 ];then
echo -n "$1" > $HOME/.config/windowmanager
#note, $HOME/.xinitrc uses this file.
fi
Files in /dev that I know for sure have whacky permissions are /dev/null /dev/dsp /dev/zero and /dev/ptymx. You have to change permissions on just about all of the /dev/pty* and /dev/tty* files to allow a normal user to run an x-terminal, the most important being /dev/ptymx.
The directory /tmp must have permissions set to 777, because all system users must be able to read as well as write in /tmp. Some programs will just plain refuse to start if they cannot access /tmp. This is not a security risk really, because nothing that important goes in there and you still won't be able to modify or delete files created in /tmp by another user.
To burn cd or dvd rom media as a user other than root cdrecord has to be suid root in Puppy. This is a known security risk and I recommend against doing it, but if you must get burning working for everybody this is how it can be done. Several distros have patched cdrtools to get around this, but I'm not all that knowledgable how to do it.
To run X as a normal user it must be suid root. There is no way around this that I know of and Puppy is one of the only distros that do not have Xorg suid root.
Doing this to tinylogin is a matter of preference though. You may not actually want another user to be able to use su. Personally I don't see a lot of harm in it.
Properly setting up sudo on a system can make administration much easier, and provides a good way to allow normal users access to functions they would normally be denied. For instance I have hacked pmount to allow a normal user to load the usb storage module using sudo, and run a script which has been carefully set up to add an entry to fstab for a pendrive, so it may be mounted with write permissions for that user. These things must be done carefully, however, or gaping security holes can be opened up in a system.
It is not a bad idea to change a couple things in /etc/fstab, either, to allow users to mount cd or dvd drives. This is done with the 'users' flag in the mount options.
[/code]/dev/cdrom /mnt/cdrom iso9660 noauto,users 0 0
Code: Select all
In addition, the command line tools for working with users in Puppy are primitive. I have added to my system the real useradd binary, because Puppy's adduser is a link to tinylogin and does not create a user correctly. Deleting users is also a proble but I haven't crossed that bridge yet.
That's enough for now I guess. Like I said I will provide some more specifics shortly, and probably some actual modified scripts. I hope to get a good healthy discussion started here and hopefully help some people who have been wanting to try this for a while. I have been developing a selection of gui tools for user administration, specifically for Puppy and derivatives, as well as systematically hacking a lot of scripts to work more generally, all of which I intend to share to interested parties.
Nathan