I think he meant that he had to use su to modify the /etc/sudoers file (likely using visudo) to give his normal user the ability to use sudo.

that is why I put mis read after I posted it. not to change everything I just added that to admit my mistake. then hopefully correctly added some helpful words afterwords.
cheers!

Yes, bassmadrigal has it right. But that wasn't very clear from my post.

If I wasn't such a heavy user of the internet I might stay logged in as root. Then again, my system probably has more to fear from me than it has to fear from any hacker.

It does make me giggle that I had to su to root to give myself permission to use sudo.

yeah I understood it after a second look after I posted that comment before the (MIS READ) then just added something else to hopefully be helpful instead. because someone else in here if not the OP stated root only single user mode preferred. whereas that does not have to take place as long as one has a system that is not being oppressed by the person putting it out to the public by hiding the root user account. therefore in essence oppressing the user too. ie Ubuntututu and Debian too use to do it, might still hide or 'remove' the root account.

I remember that post. I think he misinterpreted my desire for a single-user system. It isn't that I want to be able to just do whatever I please whenever I please. I just don't see the need to have root AND me when I'm the only person using the box. I don't see why I can't be the owner of everything and set it up so that I need to use a password to perform admin functions.

Here's a thought, what if permissions were arranged so that there was some sort of rc file that listed what groups needed admin access. I would need to sudo, or something, to change things in /etc because /etc would belong to an admin group, for example. But I could easily add new fonts or new themes to their respective directories because those would be in non-admin groups. And those ancillary directories could be relatively secure because everything in them would belong to a specific group and would be unable to act on things in a different group. I guess, essentially, I'm thinking that "groups" would effectively become "users".

I agree with that point. that is why when I started using Slackware when it was still a baby. I Always logged in as root. Ran xfce4 and I had no problems other then learning what not to do when issuing commands that can destroy your system, that can still be done in a non-root user account using su su - and sudo.


case scenario

I am in my user account I need to have root permissions. I issues a command using sudo but oops I typed the wrong thing and did what I could have done if I'd been in root. The same effect takes place.

Causes and effect


It doesn't matter. Therefore, it is not logically sound advice by that point. Then I see people in here living like logging in root and staying there all day doing whatever is an evil and should not be done.

Root account is there for a reason. else their would not be one. Even with them distros that think they know better then the operator. They hide the root account, I am assuming so this destroying of the system will have a less chance of happening. which it does not eliminate that possibility of that case scenario taking place whatsoever. Because of sudo and su and su -

they cannot completely get rid of the root account because it invalidates the reason to have root. That is like telling someone they cannot have the keys to their own car because they might crash it. So they hide the keys and leave the extra set of keys out on the table right in front of them.


temptation along with the who are you to tell me what I can and cannot do? it is my car and I need it to do whatever I want with it, It is mine.


that is easy done. You still have to type sudo but if your sudoers file does not have this line in it then you can add it to the sudoer file. you can even use the extra set of keys to do so to get yourself root permissions.

to not do that to give you yourself permission to not have to worry about it in a user account. do this, ( then GOTO down here)
just add that line into your sudo file and comment out the other one so you will not create a conflict within the sudoers file. save and you're good to go. No more having to type a password whenever you need to do something that requires root permissions.



down here
The sudoer file can be set up to give a group of people limited root permissions and lots of ways to admin on it .. google it. I am sure a lot of stuff on that will show up.

There's quite a bit of information in that post, thanks. I never realized permissions were so flexible. Guess that's another topic I'll have to do more research on. Seems the more I learn the less I know.

until you learn more then you could possibly know then your head explodes.

But that is exactly what should not be done. It is your computer and you're free to use it how you want, but the root user was never designed to be a user that someone just logs into and "staying there all day" unless that person is doing root-related tasks all day.

Linux was designed from the beginning to have follow the "principle of least privilege". This means that you should only run programs under the least permissive account. If you can run a browser as a regular user with no permissions, then you shouldn't run it as root. This protects you, not only from your mistakes (if you try to run rm -r $PKG/usr/lib64/ but $PKG isn't set, then it will have nothing there and the command would end up being rm -r /usr/lib64/), but from bugs in the code, exploits and other attackers.

WINE even has quite the warning on their FAQ about running WINE as root:

They bring up an interesting point about breaking permissions. We see permissions issues on here occasionally from people using su or sudo to run programs like Firefox while logged in as another user. This typically causes ownership of at least some of those files to change to root, so when the user tries to run them as the normal user and not root, they'll run into permission issues and the error messages aren't always obvious. (If you do want to run a GUI app as root while logged in as another user, make sure you use something kdesu (included in a full install) or gksu (available via SBo) to provide that app the correct permissions without hosing your user's home directory.

Of course it is there for a reason. It is there for administration. If you're not administrating, then why do you need the permissions to restart the webserver or the ssh daemon? If you're playing a game, why do you need permissions to edit the fstab or the passwd files? And if you have permission for that, the program you're running also does, as does every other program on the computer running with that permission. Any bugs and exploits in those programs also have full control of your computer.

The thought behind requiring sudo or su before running administrator commands is so you don't do something inadvertently. It is also thought that you will pay more attention to your commands if you're using sudo or su (which in practice, probably doesn't happen much). Those distros, mainly the *buntus aren't trying to "hide" root, they're making administration of the machine simpler. Whether they're following probably unspoken Linux guidelines is up to interpretation. But root isn't even disabled on those machines, it just doesn't have a password set up. So, all you need to do is run sudo passwd root to set that up.

The *buntus handle system administration differently than most other distros before it (possibly all, but there's so many that I have no way of verifying). sudo wasn't originally meant to turn one user into an administrator. Rather it was there to give certain groups the ability to run certain commands as root without giving them the root password. Basically, you could give all your network guys the ability to run dhcpcd, ifconfig, iwconfig, wpa_supplicant, etc as root, and you could give all your storage guys the ability to run mount, smartctl, fdisk, mkfs, etc as root. Ubuntu probably felt that simplicity was better than security to attract more people, so they decided to allow the user to do anything and everything with sudo. At that point, there's really no reason for the root user since the regular user can do everything. So, why prompt the user for a root password when they'll never use the account? It wasn't really "hiding" the root account so much as putting it in a closet since you won't be using it.

They aren't "getting rid of the root account". I have never seen any talk of this anywhere. The closest you'll find is the *buntu's since the root account just doesn't have a password assigned. In that case, you could also say that they're trying to get rid of the apache, ftp, and messagebus users since they don't have passwords either. If the distros really wanted to make getting into the root account more difficult (e.g. hide the keys to your car), they could change the default shell to /bin/false or the home directory to /dev/null. No distro has that set, because they don't care if you log in as root. You just need to specify a password before you can do so.

But you are right, it is your computer. Nobody is telling you that you can't run everything as root, they're just telling you that you shouldn't. To go to your car analogy, there is nothing physically preventing you from stomping your foot on the gas and driving 120mph in a neighborhood... but there are a lot of people, guidelines, rules, and common sense that say you shouldn't.

I'm assuming you're intending your user to be the only one being able to use sudo... if so, then why even bother setting up a group for it? You can simply just replace the %wheel with your username, which saves you from needing to add your user to the wheel group (which provides no additional benefits).

The bolded part is exactly what sudo is designed for, to give a user or group root access to a limited amount of commands... so when you set it up so your user can do everything, it isn't really following the Linux/Unix way.

But your post bounced between two completely different things. It is one thing entirely to run everything on your computer as root... it's quite another thing to give your user the ability to run any command as root using sudo. I would strongly recommend against the first, and I only explain that the second is not how it is intended to work (but I still do it on my systems).

But, as with most everything in Linux, it is configurable to your liking, even if it is against standard practices. You can even give your user the UID of 0 in /etc/passwd and effectively make them root without ever needing to actually log into root, just as you can rename the root username to something different. However don't be surprised if that causes problems, because some programs will actually not even start up if you're root.

1 members found this post helpful.

I think we may have two slightly different threads in this conversation. So I want to clarify my thoughts.

Myself, I am not talking about removing the distinct privileges between root and user. I understand why 'sudo' et al exist and I fully appreciate the need for such measures. What I don't understand is why, on a single-user box, those elevated permissions have to come in the form of an entirely different user, 'root'. Why, for example, can't my home directory simply be /home? You would have a whitelist of directories where it was "safe" to do things with regular permissions while other directories would still require "sudo" to perform actions. But there would be just one user.

Of course, I don't know if that's feasible with the way the init process works. You might need root available to take ownership of processes before there's a chance to actually log in. I'm just OCD about having things around which don't really need to be there, including ephemeral users.

You can easily set your user's directory to any directory you wish by editing its location in /etc/fstab. You'd just need to make sure the ownership is set to the correct user for /home/ so the user can write to it.

But, Linux doesn't expect people are running a single or multi-user. It is just following the FHS (Filesystem Hierarchy Standard).

Theoretically, changing your user's home directory to anything other than the standard /home/username/ should work without issue because people should be querying where the directory is rather than assuming where it is.

Keep in mind, even Windows does this with their C:\Users\ or C:\Documents and Settings\. Whether you are single or multi user, the user's home folder will be created under there.

The superuser/administrator account is just tied to UID 0. It can be named whatever you want, but root is obviously the default one. That is just the way Linux works.

As far as setting up certain directories as your so-called "whitelist", you can do that with groups and the group permissions. If you create a group called something like poweruser, then you could chgrp any folders you felt should be in that whitelist followed by adjusting group permissions as needed to match that. Then if you were to try and edit files outside of those folders, you'd need to use sudo. It's just a lot of work for, what I would perceive would be, very little payoff.

Keep in mind, some programs are very security conscious and may not function if their permissions are changed away from defaults. sudo is actually one of those. If you make /etc/sudoers world-writable, it won't even let you use sudo until it is fixed.

Don't have a look in /etc/passwd. There's a lot of users in there in a default install

But, root isn't used momentarily. If you do a ps -ef, it will show you all the running processes on your system. A lot are root owned (I have 181 on my desktop), including X, ssh, udev, and crond. A lot of behind-the-scenes processes require superuser permission, and part of that is because ports below 1024 are restricted to the superuser (root in our case). I'm not sure what imposes that requirement, but I'd imagine it is the kernel itself. This is to help you, as a remote guest, know that any services connected to within the 0-1024 port range should be legit services started by the root user on that server. It doesn't mean the connection is safe, but if you connect to an ftp server on port 21, it is likely it is a proper ftp server that the administrator set up. Compare that with connecting to an ftp server on 12452, then it is likely some random user on the computer who set it up, and you may not want to trust connecting to it.

1 members found this post helpful.

So it really boils down to this... it would pretty much take a redesign of the kernel to get Linux to operate in a fashion that appeases my OCD. The good news is that I'm not at all bent out of shape over it. I was just thinking out loud.

No worries, and hopefully you didn't take my posts to be a bashing of your thoughts. Rather, the goal was to throw information out there and let you make the decision

No bashing perceived at all. You've been quite helpful.