Douglas E Engert <[EMAIL PROTECTED]> writes: > Russ Allbery wrote:
>> This isn't good default behavior since, for instance, it will fail to >> get tokens when the user's home directory isn't in AFS. I added an >> option to request this behavior, though. > Yes, this is a problem with all the aklog programs, You cant specify get > a token for the default cell of the machine and for the cell that > contains the user's home directory. A partial fix is if the home > directory is not in /afs then don't use the -p option. Yeah, that's a thought, but symlinks and the like still make that hard. I'm going to go with the option for the short term, and in the long term we can revisit it. >> (At some point, I'm going to have to figure out what to do if the >> program to run isn't a simple program name but has some options >> attached. Oh well, I can put that off for right now.) > Actually it can be a script. Very handy for debugging. True. But that requires that the user set up the script, and for users who just need to, say, pass -524 to aklog, it would be convenient if the package could just handle such a setting. It makes it hard to parse the PAM arguments, though. I'm planning on adding an option (build-time) to link against the Kerberos libraries and then use the appdefault functions to also pull settings out of krb5.conf, the way that my pam-krb5 module does. >> Well, those are two different questions. >> If AFS isn't available, the module should log a message and return >> success. That's what it does now. > I say a lot of PAM_SESSION_ERR. For example, if the aklog program can > not be found, or the return status is not zero. Right, I'm dealing with them individually. I believe the module should print a message and succeed if: * AFS is not present (k_hasafs fails). * The module has already ran. * We're in close_session or deleting creds and the module didn't get a token successfully during open_session or setcred. * There is no Kerberos ticket cache and we weren't configured to run aklog anyway. * We were configured to ignore this user. * PAG creation succeeded but aklog failed. The module should error out if: * We couldn't allocate memory. * AFS was present but PAG creation failed. * We couldn't fork. * pam_get_user fails. * getpwnam on the user fails (applications should not open sessions or call pam_setcred for non-local users). * k_unlog failed after k_hasafs succeeded. This one is still debatable but currently is a failure; let me know if that seems wrong. * aklog succeeded but we were unable to set PAM data afterwards. This includes the fixes made based on your last message. > OK, I will buy a failed PAG, but not a failed token. But why would the > PAG fail? The main reason would faiulure of the kernel extensions to > load, afsd did not start (yet). It shouldn't ever fail, since we already verified that AFS was running with k_hasafs. But if it does fail for some reason (out of kernel memory, perhaps), I want to fail the PAM stack since we didn't isolate the user in their own PAG. >> I was going to punt on anything other than Linux for the built-in AFS >> syscall support, but after thinking about, I think I can get the system >> call number from the OpenAFS headers and add the other syscall testing >> code for the systems where this is easy. That won't cover AIX, but AIX >> doesn't use PAM anyway so far as I know. This has now been implemented, although I haven't tested it yet on Solaris. I may release 0.2 untested except on Linux and then do a quick 0.3 based on the results of testing on Solaris. > Another way to do this, is to make this routine part of OpenAFS, as it > has no Kerberos code and only depends on OpenAFS. In effect your > sys-linux.c code is the OpenAFS src/sys/setpag.c and src/sys/glue.c They > already have headers and the syscall number. Right, this is where libkopenafs comes in. The code in the PAM module is only a stopgap until the OpenAFS tree exports that functionality in a reasonable shared library the way that Heimdal does. I could integrate the PAM module into the tree and separately compile that code. The reasons why I chose not to do that are: * I think it's to the general benefit of OpenAFS to have that libkopenafs interface anyway rather than rebuilding those files internally. Other external programs besides the PAM module want to be able to make AFS system calls. I want a clean ABI here rather than building everything as part of AFS. * Forking and execing a program in a PAM module can be made to work and in some cases is the right solution, but I find it really ugly and would prefer to do without it. The long-term goal for this PAM module is to support the libkafs token interface as well so that everything can be done within one process. This means supporting building with different Kerberos libraries depending on which Kerberos implementation one uses, and that in my opinion works better outside of the tree. aklog is already a bit annoying because of the external Kerberos dependency (which keeps us, for instance, from easily distributing aklog with binary packages), and Heimdal even provides its own. * I want to be able to support Arla users with the same PAM module, as well as both MIT Kerberos and Heimdal users, and users who are using an aklog that is unrelated to either. The code they all need is basically identical, and I won't want to make them download all of OpenAFS just to build the PAM module. This argues for a separate distribution. * Just from a project management standpoint, I want to have a separate release cycle from OpenAFS. I have been releasing new versions of my Kerberos PAM module about once a month, and for this module I'll be releasing new versions even more quickly while it's in active development. I want to be able to release it based on its own stability and feature additions and not have to wait for all of OpenAFS to stabilize around a new release. > (The pam_afs2 calls the gafstoken routine that used to work on AIX, and > not fail if AFS was not load. But we don't have any AIX systems any > more. We had the MIT r* commands calling gafstoken at the right time.) Yeah, there's also code in the Heimdal libkafs to handle this case, but to do it properly, you have to use dlopen, and that's more work than I want to do in the PAM module. I'm even hoping to avoid it with libkopenafs, but we'll see. >>> +*-solaris*) >>> + if test "x${CC}" = xgcc ; then >>> + LDFLAGS="-Wl,-z,muldefs $LDFLAGS" >>> + else >>> + LDFLAGS="-z muldefs $LDFLAGS" >>> + fi >>> + ;; >>> esac >> This looks wrong. Why do you have to allow for multiply-defined >> symbols on Solaris? > Depends on the compiler and how it passes options to the loader. You > also have the option of using either the GNU loader or the Solaris > loader. Most site use the Solaris loader even with gcc. Gets real mesy, > but not as bad as on HP. That's an explanation for why there are two cases, which I get. What I don't understand was why you had to set that flag at all. muldefs means to allow multiple definitions of symbols, and this PAM module shouldn't be doing that. This isn't the same as the Linux case that's immediately above it; the Linux case is adding -z defs instead, which is: defs Disallows undefined symbols in object files. Undefined symbols in shared libraries are still allowed. Basically, what this does is throw an error at link time if any symbol in the PAM module isn't defined, which makes sure that you don't have an external symbol defined but fail to link with the shared library providing it. Otherwise, those problems are only detectable at runtime. Maybe you just meant defs and not muldefs? > There should be no need for a seperate distribution, as OpenAFS could > could do all of this, as this PAM routine has no kerberos code, only > OpenAFS code. There's no *need* for a separate distribution, but I think it makes life better for users for the reasons mentioned above. It is a drawback that they have to download and compile one more thing, but I think there are other advantages that outweigh that. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info