-
Leigh B. Stoller authored
is to add HMACs to events to ensure they that events cannot be injected into an experiment by an unauthorized client. * The frontend now generates a secret key for each experiment and stores that into a file and in the DB. * Each of the event clients, as well as the event producers (scheduler, tevc) have a new -k option to specify the name of the file. Two new event library functions were added for clients to give the key: event_handle_t event_register_withkeyfile(char *name, int threaded, char *keyfile); event_handle_t event_register_withkeydata(char *name, int threaded, unsigned char *keydata, int keylen); * When the library is in possesion of a key, it will generate an HMAC and attach it to outgoing notifications. A client receiving a notification will compute an HMAC and compare it against the HMAC in the notification. If they do not compare, the notification is dropped with a warning message printed (the client callback never gets the notification). If the client has not provided a key, then the HMAC in the incoming notification is ignored. * The scheduler also takes a -k option, and will compute HMACs for all of the static events ahead of time. That keeps it off the critical path. * The tevc client also takes a -k option. However, tevc will always try to find the keyfile (default path) so that it can attach the HMAC to dynamic events before sending them to the scheduler (which will check to make sure it matches). The scheduler will not accept dynamic events without unless the HMAC is present and matches. * I have rebuilt the elvin librarys, removing all of the X goop and the SSL goop. Smaller binaries. So, I had to add -lcrypto to all of the client makefiles to that programs link. * The program-agent got a few more changes. The command string is no longer passed inside the event; it comes in when the program agent is started, via a config file generated from tmcd data. This gets rid of our mostly insecure remote execution facility.
54bc15c4