Saturday, June 26, 2010

» sudo X applications on openSUSE

sudo is a very powerful tool when used wisely (i.e. not as it's done on Ubuntu). By default, sudo is configured in a much more restricted way on openSUSE than on, say, Ubuntu, to avoid any open security loopholes. If, nevertheless, you would like to use sudo to run X applications, here is how to do it.

Configure sudoers

First of all, you will need to configure sudo to let through a few environment variables that are normally not allowed to get through for security reasons. In order to do that, run visudo as root and add the following lines in that file, under the already existing Defaults env_keep line:
Defaults env_keep += "DISPLAY XAUTHORITY XAUTHLOCALHOSTNAME"

Wrapper script

Now, from there, the problem is that on openSUSE, the environment variable XAUTHORITY is not always set -- it is not needed for X applications, as they have the policy of defaulting to ~/.Xauthority when needed. But in order to run X applications through sudo, this is precisely the trick, as those applications need to explicitly use the .Xauthority file of the user that is invoking sudo Here is a little wrapper script that does the job. Save that as e.g. /usr/local/bin/xsudo or, if you only need it for your user, to $HOME/bin/xsudo:
#!/bin/bash
[ -n "$XAUTHORITY" ] || XAUTHORITY="$HOME/.Xauthority"
export XAUTHORITY
exec sudo "$@"
You also need to make that script executable:
chmod +x /usr/local/bin/xsudo
(of course, use the appropriate path to that file ;))

Using xsudo

Now you simply need to use xsudo instead of sudo to run X applications. Obviously, and what has not been explained here, you also need to open the loophole for your user if, e.g., you would like your user to be able to run any application as root without having to enter the root password. Be aware of the fact that this is a major security weakening, as any attacker just needs to be able to gain access as your regular user to be root on your host ! You basically loose the additional barrier of not only having to gain access as your regular user (who is e.g. running an application that is subject to a buffer overflow attack), but also requiring the attacker to know the root password. If you still want to do that, add the following line using visudo (as root), at the end of the file, and replace "jamesdean" with the name of your user:
jamesdean ALL=(ALL) NOPASSWD: ALL

Alternative

As an alternative, if you don't want to use the xsudo wrapper, you might as well also always set and export the XAUTHORITY environment variable. In order to do that, you first have to decide whether you want that for just your user, or for all users on your system. If it's just for your user, the file to append the following line to is $HOME/.profile; if you want to do it for all users, you must run the following command as root, and append to /etc/profile.local instead:
echo '[ -n "$XAUTHORITY" ] || XAUTHORITY="$HOME/.Xauthority"' >> $HOME/.profile
echo 'export XAUTHORITY' >> $HOME/.profile
Note that it's untested, and might as well hose your X startup :)

Labels: , ,

9 Comments:

Blogger Sagi. said...

If you use KDE you can use kdesu, i.e. :
# kdesu yast2
and in gnome gksudo

It will open a window for typing root password and will launch the application

Sagi.

11:23  
Anonymous Anonymous said...

It could been nice to use SandboX code in Sudo. I know, that probably sudo haven't module support.

21:14  
Blogger Jakub Rusinek said...

YaST's sudo module should be able to let us configure sudo to allow running X apps...

I've even file a bug in Novell's bugzilla and maybe in openFATE.

12:33  
Anonymous Anonymous said...

I second what Sagi said - just use kdesu or gksudo, it's much easier.

09:42  
Blogger Unknown said...

you could also add this in a /etc/profile.d/xsudo.sh
if test -n "$SUDO_USER"
then
test -z $XAUTHORITY && export XAUTHORITY=$(eval ls ~$SUDO_USER/.Xauthority)
fi

16:57  
Blogger Unknown said...

kdesu doesn't work so well in business environments on the account of needing the root password. It can be configured to use sudo but it doesn't for a reason and kde upstream wants to keep it this way, at least for now. This is a pretty good and secure fix for me (xsudo variant) for allowing my users to invoke yast in a gui as opposed to seeing the look on their faces when they must install software via curses yast.

07:41  
Blogger Unknown said...

Thanks, I have found this information very useful in our environment.

16:24  
Blogger Blaine said...

Reduce xsudo by 25% (one non-comment line out of 4). Change the body to:

[ -n "$XAUTHORITY" ] && exec sudo "$@"
XAUTHORITY="$HOME/.Xauthority" exec sudo "$@"

Unrelated: This blog needs a config change. Not displaying a date+timestamp with comment entries would be substandard but acceptable of a lacking a basic feature. But this log shows time of day without date, and that advertizes somebody trying to do something useful and failing.

Also, it's pretty bad when a Blog allows for technical article authors to somehow write code-formatted blocks, but commenters can't even use the HTML code tag.

... Wow, what junk. Has a comment preview feature which is incompatible, and totally useless because of, the comment moderation feature. I'm outa here and not coming back.

15:53  
Blogger pajton said...

Man, you are a life savior! Well, at least a-couple-of-hours savior.

Many websites are mentioning the trick with exporting DISPLAY & XAUTHORITY, but they missed the latter may be missing.

Thanks!!!

23:02  

Post a Comment

<< Home