I should start by saying that my argument is not that Linux should be a
single user environment. On the contrary, probably somewhere between
95% to 99% of Linux users should not run as root. However, I consider
myself in the minority, and I think I have justified reasons for running
as root. I am disheartened that there's no way to give a user
administrative privileges, but I am not as upset, since running as root
works so well. I have been running as root for about four months, and
it has worked exactly how I wanted. I'm glad that root has not been
crippled as a user. Root has it's own home folder, (almost) everything
treats root as if it's just another user. Perhaps someday, when less
stuff needs to be tweaked, when everything installs in a uniform
fashion, and when the system can be told to "remember password" at least
for certain applications, then I will change back to running as a user.
However, as it is now, the only way to get the convenience I want is to
run as root, and the only thing that has given me any trouble has been
xscreensaver.
> Many things will complain then. That's because you are circumvention
the
> protections. I remeber something that wouldn't work if a file in $HOME
> was world readable.
So far, the only thing that has given me any trouble has been
xscreensaver, and I think I can get around that...
> I ment as a work around when you have selected lots of files as some
> user and need to put them somewhere you don't have premission. Instead
> of starting nautilus as root and reselecting, just use root to change
> the directory you are trying to write to.
true, but that's still more work than I am doing now. and since I am
su-ing to root and changing permissions and copying files to a formerly
forbidden area, am I not creating as much risk as if I were root?
a couple months ago, I had a network share on the server that had
passwords, the server did not run as root, the client system did not run
as root. the client system mounted the share (which had read-write
permission for that user) in /mnt/nds. well, I wanted to update his
system, so I set about removing all the directories on his system except
home so that I didn't get a free-space warning (small hard drive at the
time). I did something like rm -rf /usr /var /mnt ... (wow, I feel
nervous just typing it into Evolution, hehe.) it ran for a while, and
then I got a message saying, "cannot remove /mnt/nds: permission
denied". immediately I knew what I did. Linux took me much more
literally than I would have expected, and I ended up losing all the data
in that share. at that time, I had always run as user, su-ing to root
as necessary...
another time, I installed GATOS for xfree4.3. (for some reason, GATOS
for xfree4.3 has never worked for me for any ATI card on any xfree4.3
system, including RH9, Slackware9, and a home brew Linux...but that's a
different story.) apparently it messes up the video when it loads,
which is right when it goes into X, so I couldn't even get a terminal
where I could fix my problem. of course, it's easy to fix. I just
booted off of the Phoebe CD, ran linux rescue, and extracted the GATOS
modules for xfree4.2. of course, it was an easy fix, but again it
wouldn't have made any difference if I had done that by su-ing to root
or logging in as root.
I say that I am going to mess up my computer...running as root just
makes it quicker...
> Why would "everyone in the house" need access to that?
> I haven't touched modules.conf in months. Most hardware changes don't
> even require access to modules.conf.
well, with the nVidia drivers, there are many things that can be
adjusted with the modules.conf folder. that was important for a while,
because one system here had an ALi chipset that didn't like nVidia
cards, and it was a matter of tweaking it so that it worked but didn't
slow the system down too much...
> I remember the root terminal. Not sure where it went or why.
> Most admin tacks in the GUI will ask for root's password whne it's
> needed. RHL even caches it for a short time, so if you have severalk
> tasks to do you don't have to keep typing the password.
yeah, I like how the GUI asks for the password... I usually end up
turning off the password cache, tho. :-) if root wants the user to do
just one thing, root just gives the password once. otherwise, root logs
in... of course, that's just me...
> Confused here. How often are you plan to update things like that?
> Still, installing software:
> Open terminal
> sudo rpm -Uvh package.rpm
> done.
pretty often. that's one reason that I think that we here are a special
case where we would like to run as root on our desktop systems. mainly,
though, the users here are smart enough to not break their systems when
given the chance. they have always known the root password to their
systems, so if they were determined to do something that would end up
breaking their systems, they still had that ability...
furthermore, there's no realistic way I can protect my data from the
carelessness of others except by backing it up. if I am a user, and I
save some data, then it will be in the /home/user folder, right? well,
if I leave my system logged in as user, there is the data, completely
vulenerable...
> Nautilus might ask if you try using it to install too, not sure, I
don't
> use nautilus to install. (One of my big peaves about windows is having
> to use the GUI for thangs that are much simpler with the command line)
yeah. I really liked that. I still use the terminal, because the GUI
almost never does it right. about 75% of the time it just hangs there,
not installing. I have the same trouble with up2date, even in RH9. it
just sits there, doing nothing. if I tell it to restart, then start
again, it usually works fine. however, it's easier for me to just go to
terminal, cd /var/spool/up2date, and rpm -ivh *.rpm...that always
works...
> Not sure what AIM native is, but the users could/should prpobably
> install it in $HOME instead of system wide. I have personal version of
> many apps in $HOME/bin, like OO.org and mozilla, that are too unstable
> for system wide uses, or might break someone else workflow.
AIM native is the native Linux binaries of AOL Instant Messenger. it
has more features than any other AIM client (although it is a little
buggy, and unfortunately it is not open source). it does not run like
normal programs. it has to be extracted into the /usr folder. it can
then be run by any user.
> Imagine how you feel if some user changed mozilla system wide and your
> plugins quit working. Or I change the version of perl and you scripts
> broke.
I would feel bummed out. that's not the issue here, though. I
completely agree that the vast majority of systems should be used by
users and administrated by root. here, though, we don't have any single
system that is used by more than one person (except for the main TV, and
it's a Windows system).
> Like what. You should seldom need write access to system files and
> directories.
> Are you new to Unix? Ever use it in a university or work environment?
> Few people in those setting have root access, and it works fine.
Better
> than windows, since the user cannot trash the whole system by soing
> something stupid. (try "rm -Rf /" on *nix and "deltree C:\" on
windows)
Yes, I am new to Unix. I started using it in August 2002. I have two
clients who I set up to use Linux. one client in a home network. they
rarely do any administrative tasks, so they just run as users anyway.
plus, they aren't technically inclined, so I would prefer if they log in
as users.
the other client has two offices, one in one city, the other in
another. the Linux server is in a third remote location and has a
256kbps dedicated line, and it is a server to the other two offices.
even more, the server has to be used as a workstation just like the
other offices, so a user account is active. again, I agree that running
as root would be a very bad idea there. I warned them, though, that
their main vulnerabilities in that system were the CD-ROM drive and the
floppy drive. someone could just come by, boot off of CD (disabling
that in the BIOS and turning on a BIOS password only protect the system
until someone clear the CMOS), start knoppix, and transmit the files
elsewhere, or worse yet, modify the system so as to allow his own remote
login...
> It takes some getting used to, but you learn how to seperate user data
> from system data. You will seldom need access to the system data then.
I understand, and I agree. actually, when I first set up FreeBSD, my
first flavor of Unix, I was thrilled with the separation of layers.
programs didn't have the ability to mess with data they weren't
expressly given access to, users had bubbles where all their data was
stored, far far superior to MS's "Program Files" or "Documents and
Settings" or anything like that. if I wanted to back up a user and all
his settings without unnecessarily backing up bulky programs, I just
save the /home/user folder. I love it...
> What about the lost productivity waiting for the system to reinstall,
> and the data to be restored?
that would happen anyway as I su to root and mess with my system in a
way I'm not supposed to...
> But a users doesn't need to configure X, or change the network
settings
> do they? Why would you want users installing random software on the
> systems?
we do here...
I would want users installing random software on the systems, because
it's their systems and their software. they can install whatever they
download and choose to install. this is a somewhat unique network in
that way. it has worked great for the last four months...
> Right, you make the user a member of the group.
> All the lab users are members of the group lab.
> They can access all data related to lab work. Non lab users cannot.
> Users do not need write access to the system files.
...except when they want to install or modify something, and then they
need to su to root...
> I remember when I was first introduced to *nix and the concept of
users
> versus administrators. I felt the same way. I came for single user
OSes,
> Commodores and Ataris. Then I got the chance to be root on my own
*nix.
> After trashing the system a few times, I went back to running as a
user
> 95% of the time.
I have to admit that for a little while after starting to use Linux, I
longed for single user mode again, but then I warmed to the idea, and
now I really like the multi-user, multi-tier environment. however, I
think that a number of people would benefit from running as root, and
I'm one of them. enough people would benefit from running as root that
I don't think it's right for everyone to make the blanket statement
"don't run as root". and they say it over and over, when people have
legitimate questions to ask. the xscreensaver documentation has "don't
run as root" as the answer to two questions...and it doesn't answer the
actual question. I've already benefited from running as root, in that
it has worked exactly as I had hoped (except for xscreensaver)...
> YOU create it. just like other optional files.
> I'll be you don't have .rhosts or .Xclients either.
> How about .less or .lesskey ("man less" to see what they do)
>
> -Thomas
aha! I guess it overrides some other settings, too. I guess I can
download Afterstep, install it, and create the file .xsession in my root
folder and somehow I can tell it to start afterstep. do you know of any
way I can add a new window manager to the list of options in the login
screen? I've searched around the 'net, and all I can figure out how to
do is add a window manager to RH 6.1...
thanks, you've been very helpful!
