Monday, 3 August 2009

Against the wind (su, sudo, and sucking)

The tailwind I was hoping for didn’t materialize. In fact, the wind is blowing in exactly the opposite direction. The reason? su/sudo/gksu/gksudo problems.

It is widely reported that you should use sudo to start CLI programs as root and gksudo (or the KDE equivalent) for X apps. The reason is that if you start an X app via sudo, it will take the calling party’s identity for some stuff (screen permissions, it seems) and thereby possibly corrupt ownership of files; that is, it may save a file as root that should be saved as user. And that can lead to anything from irritating to fatal problems. gksudo solves the problem by making sure everything is pointing to root.

gksudo woes

The problem with the Debbie is that gksudo seems messed up … at least when you start it with XDM or no login manager (i.e., via startx from the CLI). Example: the user isn’t in the sudoers file. You issue a gksudo rox command and you will see a dialog box that says “Permission has been granted to start without a password” (or something similar), then you see nothing more. However, gksudo is continuing to run and getting nowhere. Your sole recourse is to kill the gksudo process.

Even more irritating, if you start gksudo from a terminal with the debug option enabled (-d) it works fine. But if you do that from gmrun, it doesn’t.

So, gksudo is kinda borked. gksu has similar issues.

I’ve messed around with various ways of getting gksudo to go on the Debbie, but none of them have proven reliable. Conclusion: no gksudo for the Debbie.


So, what are the alternatives?

A custom zenity-based pseudo-sudo

You can call sudo with an -H option to point all the stuff at root (this is what gksudo does). I’ve written such a beast and it works, but with one caveat: the script does a

xhost +local:root

to allow root to connect to the users display. Otherwise, X apps will fail because root doesn’t have a display going. The xhost +local:root solves this problem, but may be creating a security issue. What I expect xhost +local:root to do is limit access to the user’s display to the user and to root on the user’s machine. But the message that xhost gives about who can connect to the display is:

access control enabled, only authorized clients can connect

which makes me think that any local users can connect.

In a one-user-at-a-time-logged-in scenario, this shouldn’t be a problem as there won’t be any other local users running that might access your display. But it still feels a bit kludgey to me.

Forget sudo and go with su and su-to-root

This is an interesting option. I don’t like the idea of ceasing to rely on sudo (it really is more user-friendly since the user only needs to remember his/her username), but su-to-root seems to be Debian’s preferred way of doing things.

One advantage of taking this approach is that the install process and new user creation won’t have to deal with adding a user to sudoers—which it currently does, but in an arguably kludgey way. A disadvantage is that a version of SkinnyDebbie for Ubuntu will require more changes (since Ubuntu doesn’t enable root password by default).

I will do some more reading up on su-to-root and make a decision tonight.

  1. mithat

    Wednesday, June 30, 2010 - 01:38:18
    states that

    [code]xhost +SI:localuser:usernametogiveaccesstogoeshere[/code]

    works and is more sercure. In the present context, I suppose the command would be

    [code]xhost +SI:localuser:root[/code]

    See also

Add comment

Fill out the form below to add your own comments