...
NOTE: The 'log_time' column indicates the time when the MySQL entry was logged (i.e. all the scripts use the MySQL NOW() function in the field for this column in all their queries), whereas the rad_attr_Event-Timestamp column contains the content of the Event-Timestamp RADIUS attribute, when applicable, which is expected to contain the timestamp of when the RADIUS server received the request.
NOTE: This database is used only by the above mentioned scripts. One more MySQL database is expected to be running on the server for FreeRADIUS, which will also be accessed by the pam_to_mysql_update.sh script to update user passwords stored in there.
shwl_add.sh
This script is intended to be run by script_launcher.py (below mentioned).
...
| PAM_USER | The system user for whom the PAM operation is running |
| PAM_AUTHTOK | The user's password (in case of a password change operation, the new password) |
| PAM_SERVICE | The service that invoked PAM (e.g. sshd when the user is attempting to log in through SSH) |
This script makes use of two MySQL databases, the one with the above mentioned 'event_log' table for logging errors, and FreeRADIUS's database for updating passwords.
This script checks, first, if it is running as root or not (the PAM stack does not necessary run as root, but as the user as which the service that invoked it is running). If it is, it proceeds to encrypt the user's password (${PAM_AUTHTOK}) as an NT hash and update it in the 'value' column of the 'radcheck' table in the FreeRADIUS'radius' s MySQL database for the entry where the value of the 'username' column matches the user's username (${PAM_USER}). Due to the nature of the SQL query used, there needs to already be an entry in the table containing the matching username in the 'username' column (for functionality it should actually also already contain the appropriate values for the remaining columns, except the 'value' column). If it is not running as root, it uses a workaround to escalate its privileges. It uses the available credentials to SSH into localhost as the user in question, causing the SSH daemon to run a new instance of the PAM stack to verify the user's credentials (and sshd runs the PAM stack as root) and thus a new instance of the script, as root. Before doing so the script makes sure that the PAM stack has not already now been invoked by sshd, in order to avoid, in case sshd should ever decide to run the PAM stack as a non-root user, that an infinite loop occurs spawning endless processes of this script, sshd, PAM, etc.
In case an error is encountered, the script logs the error to the above mentioned '@@@' 'event_log' table in MySQL mentioning "err-pmu-N" (where N is the error number) in the 'event' column, populating the 'device_username' column with the user's username, leaving the other columns empty, and exits immediately, returning the error number as exit code. The error is logged to MySQL only if the script is running as root. In case access is available to the script's stdout and stderr, a description of the error message is also printed (and the script is quite verbose about what's happening if cfg_verbose is set to 1), in case not, it is possible to look in the script's code for calls to the pam_to_mysql_update_error_message_close() function, identify the call where the error number in question is passed to the function, and the error description can be found in the same function call. The configurable options can be found at the top of the script.
...