Multiple users is a topic that comes up on a fairly regular basis on this forum. I've talked about it before, as have quite a few others. I recently made the faux pax of suggesting we might include some support for non-root usage in the community edition of Puppy and my remarks set of a volly of criticism fromcertain individuals, which I did not expect. I'd rather not hijack the thread for an argument I didn't want to have anyway so I'm starting this thread to be a central place for the discussion of how to get a multi-user setup running in Puppy, what constitutes a working setup, and what pitfalls may occur along the way.

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.

Going along with my last disclaimer I don't even intend to make a case for why a person would want multiple user accounts in Puppy. You probably know if you do already. If you don't, that is also fine with me.

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.

The most blatently root-centric script in Puppy is xwin, which constantly makes the assumption that you are root when you run it. Quite often in the script it creates files in /root or in /etc, which would normally be in $HOME. Going along with that .xinitrc must also be altered to reference files in $HOME rather than in /etc or in /root. Otehrwise not only will another user not have permission to run the X server, but there will be only one system configuration for things like the desktop icons, background, and windowmanager and all users will be locked into the system defaults.

A quick example would be the setting for which WindowManager to start:

Code:

CURRENTWM=`cat /etc/windowmanager`

This is in .xinitrc. The file /etc/windowmanager is created by xwin and overwritten every time you call xwin using an argument, ie 'xwin icewm' write 'icewm' to /etc/windowmanager. If you are not root obviously you won't have permission to do so. So we would change this snippet in xwin:

Then .xinitrc must be changed to reference $HOME/.config/windowmanager rather than the file in /etc. However, this type of issue comes up over and over again in these two files. I will provide a modified script sometime soon, when I have debugged a bit better. Currently I can run Xorg no problem using my modified xwin and .xinitrc but Xvesa is still a problem, because the video wizard also has issues.

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]

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.

Well...I'm for you Bud. Ever since I saw a mention that you were working on this I have been watching your site for info on it. I am strictly a HD user and the fact of running as root all the time is what has kept me from using puppy as my full time desktop. I have spent too many years having "NEVER NEVER run as Root" beat into my head. I'm just not comfortable doing it full time._________________"Don't tell my cattle that I have leather seats in my truck"

"I don't let my schooling get in the way of my education"...Mark Twain

Running from CD and finishing session gives the option to save. When I boot Puppy I have two potential configurations (not the same us mult-user) but did the 2.14 script also give me a password option? Someone might have suggested that . . . and I got a little confused . . .

With a password protection and an option to encrypted the .sfs file some of the important functions of multi user would be there? You will still be running as root BUT only on your configuration . . .

Maybe I don't understand the situation clearly and why MU (Mult User) needs to be available without admin / su capacity

I don't require multi user but for those sharing a machine or confidentail info on a laptop, the option would be a wonderful enhancement.

Multi-user support is just about at the kernel level in *nix. User data is stored in several files in /etc, passwd, group, and shadow (which holds the passwords in encrypted form). The OS is smart enough to be able to set some variables without doing an 'export HOME={path]' like you have to do with the xdg directories or path, etc. Just try this:

Code:

echo $HOME

It will always return the path to your home directory, no matter what user you are runing as.

As for a standard method of logging in, there is and there isn't. As in most things *nix there are various small utilities, with one of the most important being /sbin/login, which in our case is replaced with a symlink to tinylogin. Most Linux systems use runlevels and are capable of booting into text mode or graphical mode, Puppy again being an exception, which makes it's boot process simpler. This is not a big deal here. The basic configuration for each runlevel is set in /etc/inittab, which usually uses a program such as getty or mingetty (there are other varients) to get an interactive console. If nothing else is specified in inittab, these programs will run by default /sbin/login, which is in charge of authenticating and logging in a user. Most distros now defrault to runlevel 5, which traditionally is set up to get a console and then immediately run a graphical login manager. These vary but the older and slimmer ones are all but unused these days in favor of kdm or gdm, parts of KDE and Gnome respectively. A few oddballs like Vector use wdm, which is based on WindowMaker libraries and is a good deal more efficient. More on this later.

In Puppy's case we have no runlevels and a very simple inittab. There are just two virtual consoles (tty1 and tty2), and since no runlevels are specified we default to using tty1. In Puppy's inittab Barry has this set up to run the program 'autologinroot', and because of the way getty is working it runs continuously so if you log root out getty will immediately run autologinroot again.

When a user logs in, in order to set the environment up the file /etc/profile is sourced. This is where variables like $PATH or $XDG_DATA_DIRS are set. Other things can be set here as well, such as the shell prompt, default shell (yes, there is more than just Bash), etc. Since this reads as a shell script, programs can also be run in it. For example, in Slackware (and a lot of traditional Unix systems) the program fortune is run on login, giving you one of several thousand fortunes stored on the machine, many of which are just small bits of comedy. Not really useful but it broke up the boredom of an empty console prompt. In Puppy, Barry has devised a method to determine if this is the first login since bootup and if so, it automatically runs xwin. So this is how we are able to go straight into the desktop when the boot process completes.

This is all of course simplified, but it gives a general idea what normally happens when a Linux machine boots, and what some of the differences are in Puppy.

Can some of this behavior be changed? Absolutely. In the simplest multi-user setup You would leave the inittab and profile files alone and just switch over to tty2 when you wanted to log in as someone else (using alt+F2 at the prompt), once you made it possible for another user to run X that is. But by removing the call to autologinroot in inittab, you can have the machine default to a text mode login prompt. I've gone a step further in my experimentation and replaced autologinroot with a call to a graphical login manager on my machine. So far I have used slim (Simple Login Manager), wdm, and kdm successfully in Puppy, although not very successfully with Xvesa so far because Xvesa must be run with all options specified at the prompt. So when my hard drive install boots up it presents with a simple graphical login now.

There are of course issues with doing this as well. The call to xorgwizard upon first boot happens in the xwin script, along with several other basic initializations, so creating a live cd based on Puppy which goes straight to a login prompt rather than a root desktop requires some extensive modification. It is easier to leave the default behavior alone on first boot, and then change over to a different configuration for subsequent boots if desired.

I have also created a compromise configuration which will probably debut with the next Grafpup snapshot. In this configuration, root is automatically logged in but the immediately runs the command to start the login manager rather than xwin, at least on the first login of a session. So you get a graphical login, but if something goes wrong it will dump you back to a root shell. My kids don't know how to escape from X by using Alt|Ctrl|Backspace yet so this in itself is secure enough for use in my home, for the time being.

The thing is that there is no limit to the different configurations that could be run on Puppy. What I would like to do is help some other users achieve whatever it is they deem the best way to get users logged in, because I don't really think there is one right or wrong way to do it, really. I'm not a security fanatic, mind you, but I do have reasons why I don't want a root desktop coming up automatically at every boot.

One interesting story. When Flash 9 first came out one of my daughter's favorite game sites immediately upgraded all of their software so that it required the newer version. She was using the computer and requested that I install it, so I did. The next day I was still trying to figure out why all of my Mozilla browsers were crashing all the time. Then I figured out that it was the flash plugin, so I removed it. Less than two hours later, after we let her use the computer again, none of the browsers were working anymore. She took it upon herself to install the flashplayer again. I'd rather not have a situation where my ten year old kid is able to make global changes like this to my computer and break an installation for the rest of us.

I don't want to debate the merits of a multi-user system here but I will point out that this is one of the fundamental strengths of *nix over Windows. If there ever was a really potentially bad piece of malware written that attacks Linux or Unix, it would be stopped dead in it's tracks inside the home directory of the user who acquired it. No other user would be affected, and it could be very easily cleaned up. This just isn't the case in Windows, not even in NT, not even in Vista. Unfortunately it also isn't the case if you are running as root, ie in Puppy. We get by because nobody has tried an attack yet, mainly because a general attack on Linux would fail. But a general attack directed at Puppy could be devastating, were ever one launched, just the same way attacks against Windows computers can be devastating. In our case it would be so completely unexpected I think it would hurt more.

As for a standard method of logging in, there is and there isn't. As in most things *nix there are various small utilities, with one of the most important being /sbin/login, which in our case is replaced with a symlink to tinylogin

Seems the current default root login behaviour could co-exist with a multiuser login by simply doing something like this:

1-Replace the /sbin/login symlink with a shell script.
2-Add /sbin/login.bin (original login binary)
3-Put something like this in the new login script:

Nathan, I think you should redo the puppy to make it multi-user build. Why?

You may be right about one thing, that hackers don't want to hack Linux, since it's impossible. BUT however, if you want to know a story my friend told me, here it is:
(just facts, NOT really a story)

My friend told me that because he works @ NASA, he has non-root access to a MAC OS X terminal by SSH. His co worker told him that in the log file, HACKERS tried every single Windows/Linux way to hack in! Every hour, 10 attempts....

------------------------
Hear that? It is true! And it scares me! Hackers just are hungry to hack a computer for some reason......

And worse, if any hacker tried to hack puppyOS, it would be VERY easy!!!!
And furthermore, they even can delete besides my pup save files, my whole HD!!!!

This logs in jimhap, so then doing "echo $HOME" reports jimhap's home rather than root's home. Also, the home directory for user "jimhap" does not seem to exist.

I'm glad to hear there are a few people interested in multi-user support. However, I'm not ready to commit time to yet another project right now. I would be more than willing to answer questions about how to do it yourself, and share the work I have done so far. But I can't maintain and support what would end up being another fork of Puppy and a distribution in it's own right. Now, if enough people were willing to put in some sweat equity a community project could be formed around the idea.

Nathan made a nice list to start with, but I don't recall he mentioned how hard it will be do do each thing...

I think modifying the various scripts will be trivial.
Also /tmp being 777: /tmp is just created in the init script and chmod-ed (arbitrarily?) to 777...

The only thing that might be a little hard will be if we need to do some rewriting.

I think I might have found a solution to the problem with the xorgwizard:
I don't really know how Xorg runs with users, but from digging into iso's it seems like there's only the one xorg.conf and /etc/X11/Xsession is the equivalent of our xinitrc (and gets config options from $HOME/.xsession and $HOME/.Xsession).

Since in "first boot" we want Puppy to behave as before (=run as root), the xorgwizard can be run as it is now. Only root can modify (i.e. delete) xorg.conf , so we don't need to worry about the xorgwizard.

I don't know exactly where the user can specify personal Xorg settings (like screen resolution), but what we can do is have a "tweak xorg" wizard, that will enable them to set those settings. (so the xorgwizard will not be available for normal users)

The only other time the xorgwizard will run is when changing HW -- but that is something only root should do (and is not likely to be frequent on multi-user machines).

(there's another, somewhat primitive, way to personalize Xorg: each user will have xorg.conf copied to, say, $HOME/.etc/X11/ and will be able to modify it. Then, whenever xwin runs, it can link /etc/X11/xorg.conf to it)_________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

I've had the same musings and in a way miss the impenetrable shield of my 1.07 CD days. The first time I explored "naughty" sites was with puppy (by naughty think what you want but it usu involved visiting very "mc" looking message boards "not-necessarily-porn" ) Anyway. After reading this thread I thought about web 2.0 applications, thin clients, virtualization. I see a group of people both raving how open and moldable *nix OS and apps are and yet discussing how puppy needs to change entirely or at least in several delicate places which may have to be redone with any future upgrades.

What if the ftp client, web browser, chat client--ie the "reach out" applications could be re written or wrapped in code which isolates that application or forces that application to act "as if" it was limited--meaning no on-the-fly installations outside of the bubble so to speak. Kinda like running a Xen instance of a browser where Xen usually redirects hardware and accesses (as does vmware) the instance is authorized to--giving it a place to save, to run, to be free--all within a bubble. Puppy would still act as Puppy--outside of the bubbled applications. You could chose to run the application outside of the bubble (perhaps passworded--defaulting to bubbled)

This would include my man's daughter's flash plug-in dilemma where (assuming flash worked) he could allow her browser instance to contain such code and the rest of the family doesn't have to deal with it. Because the browser bubble forces her to log in to go out on the web--she is automatically operating inside the bubble--safe to download mp3's and other trojan/virus laden crap (it is coming--most of the worlds computers are not running XP and creating "creative code" for BSD, web-enabled cellphones, playstations is just a step away from *nix these days).

The most useful part of not running as root in most of our cases seems to surf safely and try out some code from time to time. I'm an integration specialist not a coder but couldn't something like an quemu, or other emulator be written/adapted to allow such control measures? If so this could probably be put as a pet package like wine would be. Xen works at the kernel level for the most part but could seamonkey be "xenified"? Any thoughts? I wouldn't be suprised if I just suggested walking straight up a cliff with regard to coding, but that's where inexperience comes in.

Interesting, but really I think in the big picture it is both easier and better to support multiple users on the system. For things like plugins they can easily install into the users home directory. Actually, on my box I have a lot of software installed just into my home, whether it might be Windows apps running in wine or things I compiled with "--prefix=/home/nathan". A lot of applications with Linux installers will automatically install into $HOME if you are not root, actually.

The thing is that workarounds are just that. I would choose to dig in and fix a system's inherent flaws 100% of the time rather than to just patch them or find ways around them. I can use Windows as a good analogy. Security in Windows is in the form of add on layers that try to fix a flawed basic design. It cannot ever be as secure as Linux or Unix because it was not designed and concieved to be. A virus or piece of spyware written for Linux could completely screw up your user account, but unless you executed it as root it would stop right there every time. That is the real reason nobody writes malware for *nix in the real world, not because of the fact that Windows has the market share (as a lot of trolls will claim).

Unfortunately as of right now none of that applies to Puppy. I'm not a paranoid idiot however. Probably the situation can continue for a while longer without any problems. At the same time though, our forums and wiki are already tempting targets for a lot of lowlife internet scum. I wonder how long it will be before they look at the os itself and do the math.

OK, lecture mode over now. I just realized I did something I said I wouldn't do, that is I debated the merits of a multi-user system.

What if the ftp client, web browser, chat client--ie the "reach out" applications could be re written or wrapped in code which isolates that application or forces that application to act "as if" it was limited--meaning no on-the-fly installations outside of the bubble so to speak. Kinda like running a Xen instance of a browser where Xen usually redirects hardware and accesses (as does vmware) the instance is authorized to--giving it a place to save, to run, to be free--all within a bubble. Puppy would still act as Puppy--outside of the bubbled applications.

puppy has had exactly that for some time. search the forum for: howto spot

Quote:

The most useful part of not running as root in most of our cases seems to surf safely and try out some code from time to time. I'm an integration specialist not a coder but couldn't something like an quemu, or other emulator bewritten/adapted to allow such control measures?

you could try running qemu (available as .pup) as spot, but it probably makes more sense to run apps like seamonkey and gaim or xchat as spot without emulation._________________sadly, it is not possible to separate politics from free software. free software - politics = unfree software.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum