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: opensuse, security, sudo
9 Comments:
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.
It could been nice to use SandboX code in Sudo. I know, that probably sudo haven't module support.
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.
I second what Sagi said - just use kdesu or gksudo, it's much easier.
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
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.
Thanks, I have found this information very useful in our environment.
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.
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!!!
Post a Comment
<< Home