Anyway, my script /usr/sbin/root2user that runs at first shutdown, works nicely -- at next boot I get a nice desktop, sound works.
After reading a bit about setuid, I started merrily putting lines into root2user like this:
chmod u+s /usr/sbin/pmount
Ahem, it doesn't work!
I found out that setuid does not work on scripts, as it is considered to be a big security hole. This site explains it, and shows how a wrapper written in C can get around the problem:
Ok, I have Wary desktop running nicely as fido, but so many scripts do not work, such as mounting drives, choosing locale, setting up keyboard, mouse, saving session (I am testing running off USB Flash, and snapmergepuppy does not work, unless I open a terminal and run 'su').
It is not just that these scripts need to run applets such as 'mount', 'umount', etc., but they also need to write to systems areas. The latter means that they must run as root.
sudo perhaps? But then, can I integrate sudo such that there is no negative affect when we are running as root? I know nothing about sudo.
Comments:Posted on 3 May 2011, 11:00 by technosaurus
I haven't worked on it in a while, but bashbox (or something similar) could workaround most of this.
ex. wrapper for root
if there is a function, it will be used instead ... so you can put all the root wrappers that you need as functions and only include them if user is root
Posted on 3 May 2011, 16:20 by 01micko
haha.. you'd remember the Mandrake days when you ran as root in X the wallpaper was a bright red! (circa 2001-2003)
Posted on 3 May 2011, 19:00 by scsijon
most unix and mainframe systems i've used over the years has this if you had superuser access, safest idea yet considering the power to stuff everything up you have.
Posted on 4 May 2011, 2:50 by Dougal
Barry, I wanted to mention it being a bad idea yesterday... Fedora are actually working on getting rid of all suid apps.
For mounting, you could just make the device nodes belong to a "media" group and add users to it... like is done with cdrom drives.