NAME
locklbtype -- lock (and unlock) label types
Perl script intended to be used under suid to a account, itself authorized to connect to the local host via ssh, as vob owner.
SYNOPSYS
locklbtype [--unlock | --nusers accounts] --vob <vob> --lbtype <lbtypes> | --help
The default function is to lock the label types passed as argument. To unlock them instead, use --unlock. Only one vob parameter is accepted, and it is mandatory. Multiple label types are possible, either with separate options or as one comma separated list. All the types must exist in the vob. For the locking function, a --nusers exception list is supported.
SSH CONFIGURATION
The account for which this script should be suid -enabled, should have a valid ssh configuration: a pair of private/public keys generated, for passwordless (challenge -based) authentication.
Its public keys should be added into each of the intended vob owner accounts' ~/.ssh/authorized_keys files.
The script connects to a hardcoded host, where ssh is configured.
DETAILS
The script sets its real uid to the value of its effective uid (owning the running process, and set via the suid bit).
It then invokes ssh on myhost.mydomain (but using its host name instead of 0 or localhost, in order to avoid recording different host keys under the same name), with the account of the vob owner, obtained from ClearCase.
Unlock events are logged, with the id and name of the real user, to a dedicated log file under the crontab account home. Lock events contain a comment with the same identity information.
This script itself is to be used from a copy in a unix directory, unless the vobs are mounted on all hosts with suid enabled. It is acknowledgedly a workaround for the lack of sudo, which would provide a simpler, better, safer and more secure solution.
Perl requires that any data obtained from the user or from a system call be thoroughly checked, and in fact re-created by any script run under an other id than the effective one (i.e. in practice, via suid). The script performs this by untainting the data, via one of several functions specialized for certain kinds of data.
Among other things, it unsets its PATH environment variable. This it must however do before requiring ClearCase::Argv, thus in a BEGIN block. The reason is that ClearCase::Argv sets the path to the cleartool binary in different way for priviledged and for normal invocations: for the latter, it uses the environment; for the former, the standard installation path. It also uses the standard path when the environment is unset. Invocation under suid is detected by comparing the real and the effective uid, which misses the case when the real uid happens to be the same as the suid account. In this case, it is important that the PATH is not wiped out between the initialization and the actual invocation.