Multiuser support fixes

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiuser support fixes

dejan555
OK, so I think it's time we fix this.
I have made some changes to slacko 5.7 files, I haven't uploaded them through git (I know, sorry!) but I'll attach them here so you can inspect them, test on your installs and keep what you think is ok or suggest/make different fixes.
Here's the archive with files and script to copy them to filesystem and set some permissions.
Extract and run "makemulti" script.
makemulti-slacko.tar.bz2

Some explanations of what's in:
Minimal /etc/skel for populating new user's home dir
inittab-AUTO and inittab-NOAUTO to switch between root autologin and login prompt
Quick "usermgr" script which I made for dpup for adding/removing users and enabling/disabling login
power-daemon and modified reboot/poweroff scripts (User shouldn't need to enter root password or even know root password for this, that's the way it was till now, if user is not root it ran sudo which asks for root password)

BTW, Barry's sudo/askpass setup isn't working in slacko, it asks 3 times for password and even I enter it correctly it treats it as wrong and exits after 3rd time.

I added a "runasroot" script which could be used to launch any command and uses su, not sudo

Fixed some customization and configuration scripts:
fixmenus now rebuilds .jwmrc in user's home dir
jwm theme can be changed for different user, still have to check other jwmconfig scripts
User can set own wallpaper
gtk theme changer didn't need any special modification it seems

Icon changer script: This is where I needed to redirect script for converting/resizing icons to /usr/local/X11/pixmaps because restricted user doesn't and shouldn't have permission to change files there, so I used $HOME/Choices/ROX-Filer/icons for new dir where pinboard will read user's desktop icons from and changed globicons in rox's config accordingly (globicons are found in .config/rox.sourceforge.net but also in Choices/ROX-Filer/globicons (latter doesn't seem to do anything usefull) )

Changed instances of /root to $HOME in xwin, rc.sysinit
Moved /etc/windowmanager to $HOME/Choices/windowmanager
Moved .XLOADED to user's home dir
Moved /tmp/xerrs.log to $HOME/.xerrs.log

Might be something that I forgot but that's mostly it for now, with these changes you will be able to add as many users you want with separate home dirs and customizations and run regular apps.

I haven't solved anything about desktop drive icons and disks management, pup_event_frontend will pop annoying password request for root (which like I said doesn't work and user shouldn't know root's pass in the first place so many of Barry's sudo/askpass scripts will have to use different approach)
delayedrun will also ask for pass (What does it have to do if root makes setup on first run anyway, can we just make it exit if not run by root?)

That's it from me now guys please inspect fixes and add what you think is needed to git.

Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

mavrothal
Very interesting.
askpass is not working because $USER has no permission to run sudo.
You can get around it by adding a sudo group and then $USER to the sudo group but then $USER becomes "admin" which I guess defies the  propose.
Runasroot is OK but then any setting changes are going to root instead of $USER and this can be an issue at times.
Should be someway to modify askpass and make it behave.
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

01micko
Administrator
We don't need no stinkin' sudo!

I run
su -c "whatever command"
 and it does the same as sudo.

I use this in Fedora-20 and Slackware-14.1.
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

mavrothal
Can you run this as a restricted user? :-o
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

01micko
Administrator
mavrothal wrote
Can you run this as a restricted user? :-o
What is a restricted user doing screwing around with system files?

The point is,
su -
requires root password. That is how it should be.
sudo
as far as I am concerned is a waste of resources. I have used redhat (2 I think) >> mandrake >> mandriva >> slackware over the past 12 years and have never used sudo in those instances. Sure, I've had ubuntu (or derivative) installs and can see BK's point that it's not all that secure requiring only user password (depending on configuration). TBH, I have no idea why he went with sudo.
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

dejan555
Yes you can run that as restricted user and that's just what my simple runasroot script does, it takes root password in Xdialog input window and pipes it to su root -c

sudo is asking for user's password, not root's? Oh man I've been doing that all wrong then I kept entering root's pass :)
I don't think we need sudo either, all scripts that have sudo at begining could be replaced with "runasroot" or however we decide to name it and use su instead.

Have anyone tried modified scripts on slacko install?
Check this out, once you run makemulti script and create user you can drop to new tty without killing root's X session (Ctrl+Alt+F2)
login as new user then launch X with xinit -- :1
Now you can switch between root's X and user's X with Ctrl+Alt+F4 and Ctrl+Alt+F5
Oh, I also changed PS1 prompt so now console session shows which user you are running as.
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

01micko
Administrator
Here is just a very simple package installation demonstrating su V sudo.. and I believe sudo is insecure, like Barry:

(OS Fedora-20-x86_64)

 [mick@localhost ~]$ sudo yum install rxvt
[sudo] password for mick: 
Loaded plugins: langpacks, refresh-packagekit
updates/20/x86_64/metalink                               |  27 kB     00:00     
updates                                                  | 4.9 kB     00:00     
(1/2): updates/20/x86_64/group_gz                          | 394 kB   00:02     
(2/2): updates/20/x86_64/primary_db                        | 8.7 MB   00:31     
(1/2): updates/20/x86_64/pkgtags                           | 1.0 MB   00:07     
(2/2): updates/20/x86_64/updateinfo                        | 905 kB   00:07     
Resolving Dependencies
--> Running transaction check
---> Package rxvt.x86_64 0:2.7.10-25.fc20 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package       Arch            Version                    Repository       Size
================================================================================
Installing:
 rxvt          x86_64          2.7.10-25.fc20             fedora          134 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 134 k
Installed size: 324 k
Is this ok [y/d/N]: y
Downloading packages:
rxvt-2.7.10-25.fc20.x86_64.rpm                             | 134 kB   00:01     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : rxvt-2.7.10-25.fc20.x86_64                                   1/1 
  Verifying  : rxvt-2.7.10-25.fc20.x86_64                                   1/1 

Installed:
  rxvt.x86_64 0:2.7.10-25.fc20                                                  

Complete!
[mick@localhost ~]$ su -c "yum install sakura"
Password: 
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package sakura.x86_64 0:3.1.3-1.fc20 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package         Arch            Version                 Repository        Size
================================================================================
Installing:
 sakura          x86_64          3.1.3-1.fc20            updates           67 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 67 k
Installed size: 188 k
Is this ok [y/d/N]: y
Downloading packages:
sakura-3.1.3-1.fc20.x86_64.rpm                             |  67 kB   00:01     
Running transaction check
Running trans[mick@localhost ~]$ sudo yum install rxvt
[sudo] password for mick: 
Loaded plugins: langpacks, refresh-packagekit
updates/20/x86_64/metalink                               |  27 kB     00:00     
updates                                                  | 4.9 kB     00:00     
(1/2): updates/20/x86_64/group_gz                          | 394 kB   00:02     
(2/2): updates/20/x86_64/primary_db                        | 8.7 MB   00:31     
(1/2): updates/20/x86_64/pkgtags                           | 1.0 MB   00:07     
(2/2): updates/20/x86_64/updateinfo                        | 905 kB   00:07     
Resolving Dependencies
--> Running transaction check
---> Package rxvt.x86_64 0:2.7.10-25.fc20 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package       Arch            Version                    Repository       Size
================================================================================
Installing:
 rxvt          x86_64          2.7.10-25.fc20             fedora          134 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 134 k
Installed size: 324 k
Is this ok [y/d/N]: y
Downloading packages:
rxvt-2.7.10-25.fc20.x86_64.rpm                             | 134 kB   00:01     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : rxvt-2.7.10-25.fc20.x86_64                                   1/1 
  Verifying  : rxvt-2.7.10-25.fc20.x86_64                                   1/1 

Installed:
  rxvt.x86_64 0:2.7.10-25.fc20                                                  

Complete!
[mick@localhost ~]$ su -c "yum install sakura"
Password: 
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package sakura.x86_64 0:3.1.3-1.fc20 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package         Arch            Version                 Repository        Size
================================================================================
Installing:
 sakura          x86_64          3.1.3-1.fc20            updates           67 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 67 k
Installed size: 188 k
Is this ok [y/d/N]: y
Downloading packages:
sakura-3.1.3-1.fc20.x86_64.rpm                             |  67 kB   00:01     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : sakura-3.1.3-1.fc20.x86_64                                   1/1 
  Verifying  : sakura-3.1.3-1.fc20.x86_64                                   1/1 

Installed:
  sakura.x86_64 0:3.1.3-1.fc20                                                  

Complete!
[mick@localhost ~]$ 
action test
Transaction test succeeded
Running transaction
  Installing : sakura-3.1.3-1.fc20.x86_64                                   1/1 
  Verifying  : sakura-3.1.3-1.fc20.x86_64                                   1/1 

Installed:
  sakura.x86_64 0:3.1.3-1.fc20                                                  

Complete!

NOTE the use of "mick"'s password when using sudo and obviously when using su root password is required.
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

dejan555
Well, now I don't like it even more.
From the top of my head, in dpup for pmount/petget/pkg_chooser I add something like this to begining of scripts:

if [ "$(whoami)" != "root" ];then
runasroot petget &
exit
fi

Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

dejan555
With same parameters passed to new process of course.
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

mavrothal
In reply to this post by 01micko
> What is a restricted user doing screwing around with system files?

In puppy all files are system files... ;)
As su you are going to do changes for the user "root" as sudo this will happen for user "mick".
So in a multiuser machine sudo makes more sense than su.

You can run `su - $USER', but then $USER must have root privileges.
If you are to do that you can simply add `$USER ALL=(ALL) ALL' to /ets/sudoers and then everything works.

However, I think a multiuser system is to assure user privacy and system integrity. Having everybody with root privileges looks like a waste of savefile space. I simpler to have different savefiles with lite encryption.
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

mavrothal
>  Is simpler to have different savefiles with lite encryption.

Come to think of it. What about if in addition to exit to prompt we also add logout that will exit to prompt _and_ umount the savefile (running first snapmergepuppy if needed) and then gives you the option to load a different savefile?
Currently this is done in the init but we could use sfs_load or similar to do that at a later point.
This will be effectively multiuser without the need to reboot or change anything else in puppy.

 
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

dejan555
But wouldn't that be double waste of space? You need 2 or more savefiles instead one and creating new user takes only 256KB of skel files to copy to /home/$USER
Also what if someone wants to make full install and have separate user configs and control what each user can do with system and disk drives, have own files that other user can't read etc...?
You also might want to have login prompt so not everyone can just boot straight into your machine and start using it.
Different savefiles are just not the answer it's not how multiuser system should work.
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

mavrothal
> Different savefiles are just not the answer it's not how multiuser system should work

I certainly agree with that.But puppy is not designed to run multiuser nor as unprivileged user.
So the first is to define what we want as "multiuser".
a) more root-like (full privileged)  accounts but with different names?
b) one root and more guest-like accounts?
c) both a and b?
Each of the above has different requirements. b (and thus c) is the tricky one.
(a) is easy. Either the additional savefile or adding $USER to sudoers with full privileges will work.
The advantage of a different save file is that if an account is compromised and given that the SFS is immutable, only the specific user is going to be affected.
Space should not be a problem and actually is preferable. Imagine if user1 fills up your save file and suddenly user2 be runs out of space even if it was plenty available on previous login/out...
   
In my mind the real problem is how to setup a fully functional unprivileged user given the puppy's architecture.
There will need some more work.

 
Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

dejan555
Puppy uses same filesystem as most other distros do and gnu/linux is multiuser by design.
It's the puppy scripts that are hardcoded for root which we can fix.
It's not that hard, really we need to just figure out how to integrate desktop drive icons and drive permissions, most of other scripts are already fixed, with my fixes restricted user can run X and regular apps and have separate customizations.
For installing apps and some setup scripts root would be in charge and user will be asked for password to run them.
Other then that I think root should have ability to add as much users he wants and grant them whatever permissions he thinks they should have (personally I think 1 superuser is enough, others can be restricted)

Reply | Threaded
Open this post in threaded view
|

Re: Multiuser support fixes

mavrothal
I think is more than some woof scripts unfortunately.
A lot of the pets out there also have hardcoded root or save config files in root, so are usable but not configurable by $USER.
Maybe is better to create a woof branch so this can mature to a more usable setup.