bwilab_scripts: support automatic uploading of log data

[jack-oquin]

for background, see: utexas-bwi/bwi_common#41

The basic approach envisioned is to create a general facility for running selected scripts on each robot under the bwilab account. The upload script will be one of them.

We will create unique public and private ssh keys for the local bwilab account on each robot, storing their public keys on nixons-head. I will write a setuid("bwilab") C program that will only run a set of scripts we maintain.

That will make it easy to upload logs without requiring a login, and also to notify the server when a robot becomes active or inactive.

[jack-oquin]

On Wednesday, I deployed the current set of scripts on 3 robots: bender, clamps, and pickles, and on 2 lab machines: zapp and nibbler.

The install went fine, following the directions in the bwi_lab README.

However, the bwilab upload did not run as expected. It should have copied the files without asking for a password, but it asked for my password. So, it looks like the bwilab command is not able to do the upload using the bwilab account authorization. I am not sure why, it appeared to work in some of my earlier tests.

[jack-oquin]

On the authorization problem: the upload script does run with effective UID of bwilab.

That depends on it being installed correctly and there not being a copy in the user's install space with a different user ID. (I believe that confused me into thinking things were working correctly earlier in the week.)

But, the rsync command uses $USER or $LOGNAME as the default for logging into the server. I think it probably also uses $HOME to find the ssh keys. But, those environment variables are being passed through by the execv() system call.

[jack-oquin]

I can run bwilab ls ~bwilab/.ssh successfully, but running the same command from within the upload script fails. I think bash is doing something funny that defeats setting of the effective UID.

[jack-oquin]

Running it under sh rather than bash works better, but there are errors with the [ operator.

[jack-oquin]

I can explicitly force the script to login using bwilab, but it still requests a password. No idea why.

[shiqizhang6]

I guess you may have to keep at least one session active, to make the passwordless uploading work. For instance, you can login the server and lock the screen without logging out. It works this way between my desktop and laptop machines.

[jack-oquin]

@shiqizhang6: I am not sure exactly what you are suggesting.

What I am still trying to make work is a setuid program that runs the upload script as bwilab. It's frustratingly close to working, and the script does run with effective UID of bwilab. But, on the exec of rsync and ssh things fall apart somehow.

I think my next test will involve setting both the real and effective UID to bwilab. I will let you know how that turns out when I have time to test it later today.

[jack-oquin]

Setting both real and effective UIDs does work. Finally!

This was a lot tougher than I expected, but with b458a89, we can do this from any user account:

 $ bwilab upload

That will copy the data under the bwilab account without needing a password.

[jack-oquin]

I believe this is working now, but will do some more testing tomorrow in the lab on various robots.

Actually uploading the data automatically will also require additions to the bwi_logging launch scripts, but that is outside the scope of this repository.

[jack-oquin]

@shiqizhang6: Are you are recommending that each user configure their accounts with an ssh key that allows password-free login to the server?

There are some disadvantages to that approach:

• Every user must do it.
• If they take the easy route and forgo defining an encryption passphrase for their private key, it will be sent in the clear on the home directory NFS network within the lab. That's a potential security hole for our server, although probably not a likely avenue of attack.
• if they do define a passphrase, then (as far as I know) that access is reasonably secure. But, can we trust everyone to do it securely?
• I personally don't much trust NFS and am not storing a private ssh key there.

The setuid approach I am using seems to work, and only depends on the bwilab account having an unencrypted passphrase for accessing the server. Since bwilab is a local account on each robot and lab system, it does not send unencrypted home directory files over NFS. I prefer that approach.

[shiqizhang6]

Thanks, @jack-oquin , for explaining the advantages and disadvantages of these two approaches. I agree with the possible issues you listed. setuid seems to be a good solution and it's good that it works.