On Fri, 25 Jun 2010 22:36:04 +0400 "Igor Druzhinin" <jaxbrigs@xxxxxxxxx> wrote: > > I think the right thing to do is to not worry about upcalls for this at > > first. Instead I think you'll want to create something like a > > "ntlminit" program that takes user, password and host or domainname and > > puts that information in the keyring. Then just fix the kernel to look > > in the keyring for that information when doing a session setup. > > > > Eventually you may want to allow the kernel to upcall for these but you > > have to figure out how that upcall should get those creds. Should it > > try to prompt a user somehow? What if the process is being run out of > > cron? > > > > To use the PAM mechanism you'll need to write a PAM module for it > > (probably an authentication module). This is also something I wouldn't > > worry about yet. That can be done later once you have the initial code > > working. > > I've already started to write some code for a project and if I understood > correctly I see its design as follows. > > Some userspace program (in my opinion, it may be mount.cifs helper program) > checks the user-specific keyring for credentials on current user name and > the destination host or domain name. If there is no one, it requests the > password else it uses them. Then it tries to mount the resource. If it's ok > then it puts the requested password or precalculated NT session key in the > payload of key of some type (own registered type or "user"), the user and > the domain name or destination server address could be saved in the key > description. On CIFS session establishing the kernel can call request_key() > and find the appropriate credentials in the user's keyring under the > description and type > > Is this a correct realisation algorithm or it should be in other way? cc'ing linux-cifs@xxxxxxxxxxxxxxx to bring the discussion to a wider audience... That's not quite what I had envisioned. The main reason for putting NTLM creds into the keyring is so that the kernel can fetch them when it needs to establish a session. Right now that only happens at mount time, but that will change when support for multisession mounts goes in. At that point, the kernel will need to be able to fetch credentials for users that were not involved in mounting the share. This would allow us to use NTLM credentials instead of krb5 creds on a multisession mount. So really what I was envisioning is a standalone program that puts username/password/domain_or_hostname into the keyring. I had sort of pictured an "ntlminit" program, similar to how krb5's kinit works today. Instead of putting kerberos creds into a ccache though, it would put NTLM creds into the keyring. Along with that, we want a way for the kernel to use this info to establish sessions. For now, that mostly occurs at mount time, but eventually we want to be able to upcall for this info on the fly so that we can do multisession mounts without requiring kerberos. >From root's standpoint with the code as it stands today, they might do something like: # ntlminit -u username -h hostname Password: # mount -t cifs -o sec=ntlmv2 //server/share /mnt/mountpoint ...mount.cifs could then be modified to look and see whether there are already creds in the keyring that are suitable for the mount. If there are, then it could skip querying for the password. > Is it preffered to register own type of key? Yes, you'll probably want your own keytype for this, but maybe one of the user keytypes would be a better choice. You'll probably need to do a little research to figure out what's most suitable. I'm not yet clear on whether a userspace program is allowed to spawn a new keytype. > Where else it is necessary to look up keyrings for credentials except > for session establishing on mount operation? During session establishment. In the current code, that's limited to mount and reconnect times. When multisession mounts go in, then it will be able to happen any time a "new" user enters the mount. The code needs to be written with that in mind. Let me know if you have other questions... Cheers, -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
