Thursday, April 14, 2011

X Forwarding with SSH and Sudo

Information: If you don't know what X, ssh, or sudo are then this document is probably not for you.  
Caveats: There are many ways to skin the proverbial cat.  One of the reasons I like Unix/Linux so much is that this ability is always present.  My solution may not match your solution, but both work just as well.
Warning:  Use these steps at your own risk!  I tend to clean as I go, so see little risk from taking the steps defined below.  Most people don't, and being lazy and careless can cause huge problems.

This "problem" is really not a problem once all the parts are put together in the right order.  Knowing the parts is like knowing the shape of the piece.  I have seen several documents on "how to configure" this, but nothing in one place that really explains what's going on.  I'm not going to be very techie with most of this, just summary.  There are lots of technical details about all the parts written and probably much better than I could write them.

X clients look for a $HOME/.Xauthority file for information.  This file is made for each new session, generally created and managed by the X server.  When we ssh -X to a host, we have no X server running.  What happens without any technical details is that sshd creates the file for us, and proxies X services through a tunnel within the ssh session.  So without attaching to graphics (X) we still have the ability to launch graphical applications.

Now, it's important to remember that the $HOME/.Xauthority is not just a pointer to the display.  There is also information in the file for security including session information. A good handy fact is that when sshd creates the file, the permission is set to 0600.

It's also important to note that $HOME/.Xauthority can be be something of a different name or location.  This is controlled  by a variable "XAUTHORITY".  For now, we only need to know that the variable is not set by default, but it can be.  What I'll show in a bit is how to use this so that you can sudo to a new account and maintain your X client abilities.

Lets say I need to ssh to a server, and run a graphical installer.  This is pretty common now days, Unix isn't all command line any more.

% ssh -X -l johndoe myserver.mydomain.com

After I'm on the console, I should be able to launch "xterm" for example and bring the display back to myself (assuming I have an X server running and allowing connections from myserver.mydomain.com.)

What happens if I need to sudo to a different account and run an xterm (given I could just run the installer, but for testing xterm is a bit lighter weight).

% sudo /bin/su - dbadmin
% xterm


Best case, I'll see an error that I have an invalid cookie "Invalid MIT_MAGIC_COOKIE" something, which means I have a ~dbadmin/.Xauthority file, but it's not correct.  Worst case, I'll see a slightly different error that I have no X server defined.  Either way, I can't launch my installer.

If I was to run strace or truss on the xterm command, I would eventually find that the problem is with my ~/.Xauthority file.  A lot of people at this time start cursing sshd or sudo thinking that they are the problem.

First things first.  Lets make sure sudo is functional.  Are we passing a DISPLAY and XAUTHORITY variable?  Are both variables being set as our initial connection?

% echo $DISPLAY
 localhost:140:0
% echo $XAUTHORITY


Well, you see that we have no XAUTHORITY being set.  In order for the dbadmin account to use johndoe's X pipe, they will need to have that set and accessable.

Add this to johndoes .bashrc or what ever equivalent log in file and language.  Now, we also need to make sure that both johndoe and dbadmin are in the same primary group.  This is important because we don't want any schmuck to send DISPLAY to your monitor.

XAUTHORITY="$HOME/.XAUTHORITY"
if [ -f $XAUTHORITY ] ; then
   chmod 640 $XAUTHORITY
else
   touch $XAUTHORITY
   chmod 640 $XAUTHORITY
fi
export XAUTHORITY

So now, johndoe has the variable set and exported (that part is important).  We have also given group read access to the file, which is more important.

Log in as johndoe again, and make sure you can see both variables.
% echo $DISPLAY ; echo $XAUTHORITY

localhost:140.0
/home/johndoe/.Xauthority

Good so far, so lets sudo to our database admin account and see if we have both.
% sudo /bin/su - dbadmin
% echo $DISPLAY ; echo $XAUHORITY
localhost:140.0


Uh oh, we have no Xauthority file.  X clients will still fail.  The problem is with a PAM module that tries to set up the xauthority for the user when they su.  I'm sure I could monkey with it and make it work, but right now I just need my dbadmin installer to run.  Comment out the entry for pam_xauth.so in /etc/pam.d/su.

So exit, and sudo back to dbadmin and you should see both entries.  If you can, make sure you can read the $XAUTHORITY file.

% strings $XAUTHORITY

If is shows you a bunch of text that you don't understand, you are ready to go.  If it errors, see where your permission setting went wrong or.. double check that group ownership is proper.. and that your primary group for both users match.

When all that works, so will your X clients.

As a final warning, there is nothing secure about graphics.  Keeping default permission on files is much better than manipulating things to make them work.  The above steps are only a way of hacking something to make it work as I needed it to work.  Use at your own risk!

Wednesday, April 6, 2011

There is no such thing as "Jobs American's won't do"

I have seen this phrase used in the past, I think we all have.  Quite frankly I find it disgusting.  This phrase is a rhetorical trick, trying to get the average person to believe that businesses and politicians are doing them a favor by not doing their duties and protecting US citizens.

Lets call this what it really is.
  • Jobs Employers don't want to may minimum wage for.
  • Jobs Employers don't want to pay taxes and insurance for.
When it comes to jobs inside the United States borders these are more properly "Jobs people and companies break the law for, and receive little to no punishment."

While some of us may see some of the short term financial benefits from the practice (lower priced goods) our society and country as a whole is losing, and losing a lot.

Factory jobs were moved overseas which cut jobs and income from middle class Americans.  As indicated by unemployment rates over the last 10 years and the economic troubles for middle class Americans, have we as a nation seen any benefit outside of the top 1% of income earners earning more income from the policies of NAFTA or not punishing those breaking the law by paying illegal aliens under the table to perform jobs?  Has wealth disparity in the US improved?  The answer to both of those questions is provably false.

Daily we have immigrants performing jobs that teenagers and young adults would perform in the past.  This of course gave our younger generation liquid income to spend and keep the economy moving, in addition to work experience.  This income is now pulled outside of our borders and reduces spending in the US.  What 20 years ago may have been someones college money, or first car, or money for the prom or their first date, is simply no longer there for them.  The money is in Mexico or some other foreign country.

Before people began to break the law and damage our economy, all of these jobs were being done by Americans.  If we enforced the current laws and protected our citizens, those jobs would still be done.  As in the past, those jobs would be done by Americans, spending that money in the US economy, which in turn keeps the US economy healthy.

The duty of our politicians is first to the American people.  If we have surplus, sure, we should absolutely help out people in other countries where we can.  If the US unemployment rate is at 9% (declared) in the US, is it our Government's duty to provide money for a poor family in Mexico or put an American person to work?  Obviously, the latter is the duty of our Politicians.