It's probably a good idea to at least copy one of the MIT Kerberos lists on bugs yu find in our code. We don't tend to read the OpenAFS lists and we don't suddenly become aware of issues that aren't brought to our attention.
I was actually very close to doing that until I got mail from my MIT friend that said the problem was intentional.
Let's assume that MIT's kinit for KFW did accept passwords on
stdin. Would you have had to modify any of the AFS code or is
there already a facility for starting a shell during the afs login
process?
Smart, you've caught me. There is no built-in facility for starting a shell in OpenAFS. I make a small change to "afslogon.c" to exec a shell at the point where K4 authentication is normally done. This small change requires no extra compile-time headers, or run-time dependencies. This is known as the AFSLogonShell. See...
http://www.coe.uncc.edu/~rmdyer/afslogonshell.htm
Frankly, I'd love to see this "shell" facility added into OpenAFS. It actually makes AFS on Windows much easier to manage because it solves -so- many problems. Example...
1. K5 authentication can be done using "off-the-shelf" binaries..."kinit" & "aklog". I can override the internal K4 authentication if I want, or allow the error status to be processed.
2. Roaming profiles are easier to setup.
3. Folder redirection is much less complicated to setup.
4. The AFS service and global drive can be tested at user logon.
5. Quota and user volumes can be checked at logon.
6. The shell exec can be configured to call any scripting language interpreter or process.
Without the shell feature we are limited to the current K4 authentication of "afslogon.c" and there's no way to perform any logon scripting before the user's process space has been init'ed. Microsoft's logon scripting is limited to the post-init environment. At that point, folder redirection is all but impossible to setup.
I could rave all day about how much I like the "shell" feature, it doesn't change the fact that anyone can download the code and do what I did. The "afslogon.dll" file is simply a Microsoft logon provider. There isn't really anything special about the fact that it does AFS authentication. It's just a DLL file that exports certain functions to the Winlogon process. You can add multiple logon providers just like you can glue together pam modules. I "could" have written my own logon provider DLL and "shelled" out of that. That wouldn't have been any different. I just thought, hey, why write my own, here's a perfectly good one that ships with OpenAFS. All the logon providers "get" the plaintext password.
Why can't you guys modify "kinit" so that it check to see of the username is "system"? If it is, then you allow the pipe, if not, then dont. Simple enough? Oh, not so simple, this won't work on Win9x series...
Rodney
_______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
