gksu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gksu invoking sudo


From: Paul Smith
Subject: gksu invoking sudo
Date: Wed, 29 Oct 2003 11:20:50 -0500

Hi all;

Gustavo asked for more info on my xsudo script that I posted here a week
or two ago.  Here is a line-by-line breakdown of the script I sent:


Basically, the method the script uses is to create a temporary
Xauthority file containing the user's XAUTH cookie, then invoking the
command with the XAUTHORITY environment variable set to point to that
temporary file.

Once the command is complete we delete the temporary xauth files.

Comments below refer to the code just _above_ the comments.

> xauthdir=/tmp/.xsudo.$$
> xauthfile=$xauthdir/.Xauthority

If someone can get your XAUTH cookie then they can get access to your
desktop, so it's critical that we protect it.  I do this by creating a
directory in /tmp owned by the user and with mode 700.

> [ -d $xauthdir ] && die "ERROR: xsudo private directory '$xauthdir' exists!"

We don't continue if the directory already exists... this helps to keep
DOS and other types of errors at bay.

> cleanup () {
>   rm -rf $xauthdir
> }
> trap cleanup 0 1 2 3 10 12 14 15

Set up so when the script dies everything gets cleaned up.

> # Create the private directory for this invocation
> mkdir $xauthdir || die "ERROR: cannot create private directory '$xauthdir'!"
> chmod 700 $xauthdir || die "ERROR: cannot chmod '$xauthdir'!"
> 
> touch $xauthfile || die "ERROR: cannot create file '$xauthfile'!"
> chmod 600 $xauthfile || die "ERROR: cannot chmod '$xauthfile'!"

Here we create the temporary directory and xauthority file and die if we
can't get exactly what we want.  If this is done from a program of
course it can be made significantly more atomic and less error-prone.

> xauth nlist $DISPLAY | XAUTHORITY="$xauthfile" xauth nmerge -

This is the key to the whole thing: we run xauth nlist to get the XAUTH
cookie for the current $DISPLAY, and we pipe it to xauth nmerge with an
override of the XAUTHORITY environment variable to write the cookie to
our temporary xauthority file.

I'm not an X hacker so it's not clear to me how best to do this from a
program like gksu: does X have an API where we could perform these steps
directly rather than invoking the xauth program?

> # Now run the command
> XAUTHORITY="$xauthfile" sudo "$@"

Now we invoke sudo with the command line, and XAUTHORITY set to our
temporary file.


Since the command we're running is run as root, it has full access to
read any file in /tmp even if it's not owned by the user, so we don't
need to ensure that the temporary file is owned by root.

It's not clear to me why this is different between su and sudo: doesn't
trying to invoke graphical programs with "su" run into the same
difficulties with XAUTH cookies?  What exactly was the problem with
sudo support?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>   HASMAT: HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]