dtgreet hack

dtgreet hack

We had an occasion where we wanted to demo some Sun Rays in a controlled environment to a whole whack (200+)of customers. Basically we wanted to demonstrate the Sun Ray's ability to hot-desk. To that end, we had a custom application written that would prompt the customer for some trivia answers. The answers to these questions were posted around the demo site, so that the customer would have to visit each Sun Ray to find the answers. And since he was there anyways, he could pop in his Smart Card and answer the question right then and there.

However: we wanted to give certain user accounts access to a full desktop system, so that desktop capabilities could be demonstrated to the prospect under the supervision of a sales associate. And for various reasons, we had to use the same Sun Ray cluster to do both things.

Out of the box, Sun Ray Server does not give you the ability to do this. You can run Smart Card clients in CAM (Controlled Access Mode), or you can give them a full desktop (ie access to the login prompt).

Sun had provided us with a script which could tell the login process who was attempting to log in based on the Smart Card which was in the Sun Ray they were using. The goal here was to make sure that the person holding "steve"'s card was not trying to log in as "rick". So we knew that we could have the startup scripts recognize certain cards, and therefore do different things for different cards.

The problem was that we wanted those certain cards to effectively short-circuit the login process. So the decision had to be made before the system got around to popping up the login gui.

After a bunch of fumbling around, we hit on the idea of replacing /usr/dt/bin/dtgreet, which is the program which actually pops up the login challenge.

So what we did was move /usr/dt/bin/dtgreet to /usr/dt/bin/dtgreet.save (because for some users we will want it), and installing this script as a replacement /usr/dt/bin/dtgreet:

#!/bin/sh
PATH=/usr/bin
DISPLAY=`echo $XAUTHORITY | sed -e 's,.*:,:,' -e 's,-.*,,'`
        UTDEVROOT=`echo $XAUTHORITY | sed -e 's,.*:,,' -e 's,-.*,,'`
#       UTDEVROOT=${UTDEVROOT%.*}
        if [ "$UTDEVROOT" != "" ]
        then
                DTDEVROOT=/tmp/SUNWut/sessions/$UTDEVROOT
                UTDEVROOT=$DTDEVROOT/unit
                export DTDEVROOT
                export UTDEVROOT
        else
                unset UTDEVROOT
        fi
MYMAC=`cd $UTDEVROOT; /usr/bin/pwd | /usr/bin/sed 's/.*(............)/1/'`
MYTOKEN=`/opt/SUNWut/sbin/utuser -Lc | /usr/bin/grep $MYMAC | /usr/bin/awk '{print $1}'`
TOKENTYPE=`echo $MYTOKEN | /usr/bin/awk -F. '{print $1}'`
SCUID=`/opt/SUNWut/sbin/utuser -L | /usr/bin/grep $MYTOKEN | /usr/bin/awk '{print $4}'`
case "$SCUID" in 
"sales1")
        exec /usr/dt/bin/dtgreet.save $*
        ;;
"sales2")
        exec /usr/dt/bin/dtgreet.save $*
        ;;
"sales3")
        exec /usr/dt/bin/dtgreet.save $*
        ;;
"sales4")
        exec /usr/dt/bin/dtgreet.save $*
        ;;
"sales5")
        exec /usr/dt/bin/dtgreet.save $*
        ;;
"root")
        exec /usr/dt/bin/dtgreet.save $*
        ;;
esac
export DISPLAY
/usr/openwin/bin/xhost +
/usr/openwin/bin/xset s off
/bin/su - demo -c "export DISPLAY=$DISPLAY; /usr/bin/default_application"

Next, you have to prepare the "special" cards (ie the ones associated sales[1-5] and root) in the Web Admin GUI. For the "name" and "other data", we put the relevant user account string. (You probably only need to put it in one or the other, but we didn't spend the time to figure out which.)

Finally, we put it into the mode where it requires a Smart Card to run. When there is no Smart Card in the Sun Ray, it only displays the give me a Smart Card icon.

So now you have it in a mode where any inserted card should give you the /usr/bin/default_application, and the special cards should give you the login gui. And in fact, we did, as far as it went. However...

Of Course It Isn't That Simple

There are some problems with this approach.

Firstly, there is the security issue: we had to issue the xhost + prior to handing off to our default application. This exposes the application session to anyone with network or local (ie another Sun Ray session) access to the system. This is bad. It is obvious that dtgreet (or its successors) have to do something to securely pass control of the display to a user process; ideally we would learn what this process is and duplicate it. But we didn't have time.

Secondly, the hot-desking of the default_application doesn't entirely work. We discovered at the demo site that if the session is left disconnected for a certain period of time (approximately 30 minutes appeared to be the threshold) the session would exit, and re-insertion of the Smart Card would bring up the beginning of the default_application again. We have no idea why this was happening; the xset s off is an attempt to squash the built-in screensaver, in the hopes that this was the offending mechanism. It didn't work.

So our demo was not a huge success.

Upon Reflection, After The Fact

After the fact, it occurred to me that the Sun Ray Server already has to make a similar type of distinction. You can place the Sun Ray Server in a mode where only "registered" Smart Cards are accepted. (Unregistered cards are rejected, or the user is given the option of self-registering his card.) This strikes me as the logical place to do our execution path selection, not in mangling dtgreet. However I do not at this time know where to start looking in the startup process to find this.

It definitely qualified as an Interesting Problem, and was perhaps the most fun I've had solving a problem in quite some time.