Web Site
Developers
Thoughts About Ubuntu 8.04 - Pseudo Root User
Complaints Against Ubuntu's Sudo User
I have read a number of heated complaints about Ubuntu's default implementation of sudo privileges in preference to simple root access. While I have issues with some of Ubuntu's implementations and features, this is not one of my complaints. Indeed, I prefer it. I have an administrative account that has sudo rights that I do not normally use. My activities are primarily restricted to another user's account that lacks any machine administrative rights [1.]. However, I use a single command to gain full root access rights when I desire it. Perhaps those driven away from Ubuntu due to this one issue might reconsider.
Single Command to Ubuntu's Root
I have seen this command a number of times now, however, when I was working with Phil Howard and Bill Lubanovic [2.] on a project both [3.] showed me this command:
:~$ sudo su
More realisticly, here is how it works:
[sudo user]@[machine name]:~$ sudo su [sudo] password for [sudo user]: root@[machine name]:/home/[sudo user]#
But note, that even this privileged user is still in their home directory. Nonetheless, they can work on files far afield:
root@[machine name]:/home/[sudo user]# ls -ltr /home/[regular user]/[path]/ -rw-r--r-- 1 [reg. user] users 165 2008-10-03 09:21 ubuntu-8-04-[notes].txt~ -rw-r--r-- 1 [reg. user] users 718 2008-10-03 09:46 ubuntu-8-04-[notes].txt root@[machine name]:/home/[sudo user]# emacs \ /home/[regular user]/[path]/ubuntu-8-04-[notes].txt &
where the backslash "\" helps to keep the fixed format text within most boundaries. After editing and saving the file, I suggest checking the file ownership and changing where necessary:
root@[machine name]:/home/[sudo user]:# ls -ltr /home/[regular user]/[path]/ -rw-r--r-- 1 root root 718 2008-10-03 09:46 ubuntu-8-04-[notes].txt~ -rw-r--r-- 1 [reg. user] users 830 2008-10-03 10:03 ubuntu-8-04-[notes].txt root@[machine name]:/home/[sudo user]# chown [reg. user]:users \ /home/[regular user]/[path]/ubuntu-8-04-[notes].txt~
Again, be cautious, check to be certain the changes took:
root@[machine name]:/home/[sudo user]:# ls -ltr \ /home/[regular user]/[path]/ -rw-r--r-- 1 [reg. user] users 718 2008-10-03 09:46 ubuntu-8-04-[notes].txt~ -rw-r--r-- 1 [reg. user] users 830 2008-10-03 10:03 ubuntu-8-04-[notes].txtAnd after another edit:
root@[machine name]:/home/[sudo user]:# ls -ltr /home/[regular user]/[path]/ -rw-r--r-- 1 [reg. user] users 718 2008-10-03 09:46 ubuntu-8-04-[notes].txt~ -rw-r--r-- 1 [reg. user] users 1820 2008-10-03 10:08 ubuntu-8-04-[notes].txt
I was surprised by several of these results. In the first save, I thought the regular file would change ownership to root. And I was pleasantly surprised that the change persisted, retaining the regular user's ownership over several file saves. This is the way it worked on my machine using the Ubuntu 8.04 desktop, should I be using another distribution I would not assume these rules would hold. Indeed I would be leery of assuming it held even for the next version of Ubuntu.
Non-sudo Ubuntu Users
As a regular user, but one that knows the sudo password I have seen many times that I cannot access those rights. Nonetheless, what I saw today surprised me. In the first two tried I used the root password and in the third used my own:
[regular user]@[machine name]:~$ sudo su [sudo] password for [regular user]: Sorry, try again. [sudo] password for [regular user]: Sorry, try again. [sudo] password for [regular user]: Sorry, try again. sudo: 3 incorrect password attempts
The responses were invariably polite, however, being explicitly cut off at three attempts was new to me. Moreover, it differed markedly from my first try where I just botched the password (essentially erasing the input) and on the second try inserted my user password. This was the response that time:
[regular user]@[machine name]:~$ sudo su [sudo] password for [regular user]: Sorry, try again. [sudo] password for [regular user]: [regular user] is not in the sudoers file. \ This incident will be reported.
The "beat it!" content of that last message is consistent with another observation I have functioning as a regular user. Unlike the 6.06 desktop, I see no sign of when updates are ready on 8.04. This implies that this newer desktop is targetted or already used in company installations where it makes sense to not distract uses with maintenance issues they cannot address. However, I happen to think this is a weakness for a single or small group user maintained machine, e.g. SOHO. Therefore, I set about trying to learn why 8.04 now operated this way.
Non-sudo Users - Update Notifier
Again my "solving" this problem occurred very late in the composition of this artilce. Indeed, I had no clue for the reasons until I had nearly finished the text just above this section. Here is what I tentatively know: the update notifier is a session process. That process was not running on the regular user account, but was shown as being an active startup program when examined by this menu sequence (within regular user account):
System>Preferences>Sessions>Startup Programs (tab)>(checked) Update Notifier
from which I got to this shown screen below by highlighting the last mentioned and hitting the "Edit" button:
Figure 1. Ubuntu 8.04 Edit Screen for Session Preferences for Startup Programs as seen by Non-Sudo User
While the screen gives the impression that it is editable by a restricted rights user, whether it truely is or not, is not the issue. The paramount issue is, it cannot be seen running within the regular user's session. Using this command copied from a link found searching the Ubuntu help [4.]:
[regular user]@[machine name]:~$ ps -ef | grep [u]pdate-notifier [regular user]@[machine name]:~$
It just shot back to the prompt not even showing the grep attempt. Nonetheless, I found it as one of the listed processes running on the sudo user session, despite not making a call to those rights. In contrast, the sudo user for a similar command sees this:
root@[machine name]:/home/[sudo user]:]# ps -ef |egrep update [sudo user] 8004 7868 0 09:23 ? 00:00:00 update-notifier root 11554 11499 0 11:35 pts/2 00:00:00 egrep update
I had hoped that I might trip across the proper config file that needed alteration to have this process running on a selected low rights user. But despite my dislike of GUI configuration tools I found a way by gut instinct to have this work. Moreover, upon reflection, I understood how it made sense, however, not without costs that I will mention later.
One method I rejected was giving administrative rights to this user, because it negated my desire to separate the user types and functions [5.]. My desire was to limit unintended use of root level rights that might be acquired by an outside party. If this is not a big issue, go to the menu in your adminstrative account (no need yet to up your access level) and start here:
System>Administration>Users and Groups>User Settings
select the unprivileged user and hit the unlock button. At this point your administrative account password is required. [The steps that follow seem reasonable, but were not tested. Therefore, use caution. If something odd happens be prepared to follow a different recipe.] I would have chosen the Properties button on the right side and looked at the User Privileges tab list. I think checking the "Administer the system" would have made this account a fully sudo user. Again this was not the path I took.
It was obvious to me I needed to alter some sort of init file that was attached to the startup of an X session. Nonetheless, I was flying near blind when I essentially did this using the Ubuntu GUI tools, GUIs do that to me. Here is what I did and near as I can reproduce without running the entire course again. Start again with this menu sequence shown above up to the point of unlocking the unprivileged user, then in the "Users Settings" box select "Manage Groups" button. Another box comes up titled: "Group settings". I went down to the gdm line (highlight) and hit the "Add Group", with a sickening feeling. The latter sense was due to knowing I had added a lot exposure to this account, a consequence I would have preferred to avoid. On checking as that user I now saw the notifier active:
[regular user]@[machine name]:~$ ps -ef |egrep update [sudo user] 8004 7868 0 09:23 ? 00:00:00 update-notifier 1001 8448 8420 0 09:32 pts/1 00:00:00 egrep update
Notice the owner of the process. But there was a price, running the active process listing without the grep filtering, I have a much larger set. The consequences are unknown. Thus, while I have found a solution the result is suboptimal.
Summary
While I can understand people's irritation with Ubuntu's significant flaws, I find the security model to my liking. Where I needed persistent root access, the simple command: "...:~$ sudo su" provides it where I need it, i.e. within a terminal window. Moreover, I prefer to separate my regular user identity from the more privileged maintainer. Thus, while it is not one of my core reasons to keep using Ubuntu's desktop, I am certainly not repelled by it.
I also like the localization of the root level rights. Those rights are not automatically transfered when another independent application is opened. Some might question the need to retype the root password, when doing a quick update. However, what if you need a reference and unthinkingly open a browser. Regarding the latter, I have done it and missed the visual clues indicating I was doing something dangerous and dumb. That is why I think this portion of the Ubuntu security model seems to have been done well.
Corrections, suggested extension or comments write: H. Cohen.
© Herschel Cohen, All Rights Reserved
Return B/ST Home or Problems Page
____________________________________________________________________
1. Currently I am the only user of this machine. Return
2. Co-author: Linux System Administration, O'Reilly, 2007.
Return
3. At this time, I cannot remember with certainty, which one
gave me the command first. Return
4. Actual link lost in the haze of extensive, mostly
unproductive searches. However, I think, but not certain,
it was an internal Ubuntu form message. Return
5. I have a hint that Policy Kit built into Ubuntu might
afford finer grain settings on administrative rights.
However,trying to decode the meanings of the settings
looking only at the GUI confuses me. Only three options
using the same ill fitting set of choices. I could pour
over the documentation, however, I just lack the energy
at this time. Return
____________________________________________________________________