Unfortunately no. I have brought up some suggestions, however.

My ideas involve adding the following: 1. Adding into the P4 protocol the "real" username. Such that the P4USER variable can be ignored, and to allow administrators to masquerade as another user as needed. The permissions will be based on the "real" username, which is retreived from the OS. The effective user would be the P4USER variable. The P4USER variable would be used only for users with "super" protection rights. In effect, this uses the client's OS mechanisms for authentication.

2. Adding the ability to limit client versions (e.g.. 2002.2+) and host types (e.g. disallow windows), so that #1 can't be subverted by using an older version of the client. This also means that you'd be able to force people to upgrade their clients. Appropriate logs would be generated for bad versions. There should be options to log, permit and deny. Lines are processed until a match is found. For example:

[permit|deny|log|permit+log|deny+log] [[user|group] name|* *] [[-]version[+]|hosttype]...

3. An authentication call out. This would slow down operations, but would increase security. If you trust the systems in your company, (e;g. they are all corporate Solaris boxes), then #1 could handle authentication. For those employing Windows 9x/Me, or where root access is accessible to "owners", then this is more important.

4. When using the CLI, the ability to be asked, just once, for your password, and then have it saved in the shell's memory (as an environment variable). the password should be hashed, and should not be written to disk, so that when that shell terminates, the password is gone. Setting the password into the Window's registry (using P4Win) has a similar effect, in that it is hashed (or at least, it appears to be).

5. The ability to configure all of the above!