[00:09:42] If there a new symbols and the soname hasn't changed, then the library author has goofed up. You can't build on a machine with one ABI, and then run on another. [00:18:37] --- jaltman has left: Disconnected [00:19:05] --- jaltman has become available [00:19:07] --- Jeffrey Altman has become available [00:32:41] --- dev-zero@jabber.org has become available [00:57:23] --- Simon Wilkinson has left: Lost connection [01:10:45] --- abo has left [01:38:25] --- dev-zero@jabber.org has left [01:45:57] --- jaltman has left: Disconnected [01:46:37] --- Jeffrey Altman has left: Replaced by new connection [01:46:38] --- jaltman has become available [02:42:58] --- jaltman has left: Replaced by new connection [02:42:59] --- jaltman has become available [02:53:38] --- Simon Wilkinson has become available [02:57:43] --- Simon Wilkinson has left [02:57:46] --- Simon Wilkinson has become available [03:03:02] --- Simon Wilkinson has left [03:27:29] --- haba has left [03:38:05] --- haba has become available [04:23:38] --- dev-zero@jabber.org has become available [04:28:41] --- Simon Wilkinson has become available [04:47:11] --- deason has become available [04:47:14] --- dev-zero@jabber.org has left: Lost connection [04:56:03] --- haba has left [05:03:34] --- dev-zero@jabber.org has become available [05:06:32] --- dev-zero@jabber.org has left: Lost connection [05:17:39] --- dev-zero@jabber.org has become available [05:31:12] --- deason has left [05:33:05] I apologize for the stupid question but do the openafs debian packages already have a dependency on an explicit mit krb5 distribution? [05:34:37] They'll have a dependency on a specific soname. [05:34:59] you mean heimdal versus mit or do you mean more specific? [05:35:22] I guess Jeffrey is worried about the "built against 1.8", run against 1.7 case. [05:35:41] Which is protected against by the linker, rather than the packaging system. [05:35:47] indeed [05:38:16] --- reuteras has left [05:38:54] --- reuteras has become available [05:47:56] --- haba has become available [05:50:09] I am concerned that if we are going to put users in a position where if they upgrade openafs they must also upgrade krb5 [05:50:47] We're not. Debian might be, but that's a choice for Debian. [05:53:45] On Windows, I would address this with a run time test to load the symbol by name only if it exists within the dynamic library. [05:54:09] That's not the Unix way. [05:54:37] An OpenAFS built against MIT Kerberos 1.8 simply won't dynamically link against MIT Kerberos 1.7 [05:54:45] Irrespective of what symbols we use. [05:55:08] The same is true in the other direction. If you build against 1.7, you can't kink against 1.8 [05:55:11] s/kink/dynamically link/ [05:57:25] then my concern is valid. users either need to build openafs aklog themselves or we will find ourselves with a need to distribute packages with different krb5 dependencies. [05:58:23] Nope. [05:59:06] A distribution is pretty much defined by the version of the libraries that it ships. [05:59:10] no. debian ships what they do [05:59:26] and we build current openafs against what current debian is for any debian release [05:59:26] If I take, say, Fedora 11, and want to upgrade MIT Kerberos on it, then I have to rebuild everything on that system that is built against MIT Kerberos. [05:59:33] so we depend on whatthey have [05:59:43] you build your own kerberos? not our problem [05:59:47] And Debian won't change the version of MIT Kerberos (or any other system library) in a release. [05:59:51] yeah [06:00:48] ok [06:43:21] --- haba has left [06:45:14] --- haba has become available [06:52:39] --- reuteras has left [07:23:15] --- Simon Wilkinson has left [08:09:36] --- kaj has left [08:11:05] --- jaltman has left: Disconnected [08:11:08] --- jaltman has become available [08:12:25] --- kaj has become available [08:14:51] --- dev-zero@jabber.org has left [08:27:20] --- Kevin Sumner has become available [08:28:02] --- jaltman has left: Lost connection [08:32:20] --- Simon Wilkinson has become available [08:40:10] --- Simon Wilkinson has left [08:54:34] --- jaltman has become available [09:16:57] --- kaj has left [09:23:13] --- haba has left [09:43:43] --- jaltman has left: Disconnected [09:46:40] --- bpoliakoff has become available [10:25:54] I don't think we distribute prebuilt binaries of aklog linked with some MIT Kerberos library anywhere except for Red Hat and Debian, do we? [10:26:05] Well, maybe Solaris, but they don't have the same issue. [10:26:53] macos (ships with mit) and solaris (weird special case) [10:27:15] And both Mac OS and Solaris haven't disabled DES by default. Yeah, we should be okay for our binary distributions. [10:27:52] Mostly my concern is for the next Ubuntu release, which is freezing soon, since right now the OpenAFS aklog in Debian doesn't work with the MIT Kerberos release that's going to go into that release. [10:29:43] --- dev-zero@jabber.org has become available [10:29:57] --- dev-zero@jabber.org has left [10:30:10] --- dev-zero@jabber.org has become available [10:40:28] --- kaj has become available [10:41:56] --- kaj has left [10:47:06] --- kaj has become available [10:56:55] Gah, want to find time to clean up aklog code... [10:57:06] --- meffie has become available [10:57:28] --- dev-zero@jabber.org has left [10:59:55] --- jaltman has become available [11:04:47] --- deason has become available [11:08:29] --- Simon Wilkinson has become available [11:09:14] Russ: It'll all be going to a better place sometime soon ... [11:09:31] Oh, yeah, maybe not worth the effort. [11:09:56] But man. [11:10:13] Take a look at klog - now that will rot your mind. [11:10:13] I mean, just for starters, the error handling is horrible. [11:10:40] No Kerberos code should use com_err directly for reporting Kerberos errors any more. [11:10:51] The loop in which it goes through all of the different principal variants is very exciting. [11:11:14] Well, I think aklog dates from the point that it was handling both AFS and Kerberos errors using the AFS com_err. [11:11:24] Yeah, I know. [11:11:39] I don't fault Ken; it just needs serious love to be a modern Kerberos program. [11:11:56] Yeh. [11:12:36] We also should look at dealing with the shared code between it and klog. The fact that they both have their own (slightly different) pick-a-service-principal logic doesn't help matters. [11:13:24] Yeah, I was noticing that too. [11:13:33] Not to mention that all the ticket munging is basically cut and paste of the same code. [11:13:38] I wish the logic in aklog were a library so that it could just be called by klog with the appropriate cache [11:13:43] Yeh. There's a lot of that about. [11:13:46] That was the long-term goal. [11:13:52] To roll it into kopenafs. [11:13:59] Well, klog and aklog are fundamentally different. [11:14:06] klog doesn't get a TGT. [11:14:14] And provide the same API as Heimdal. [11:14:19] what is love serious about? [11:14:26] Error handling. :) [11:14:30] --- deason has left [11:14:44] --- deason has become available [11:14:54] You'd need to have the principal selection logic, and then have a helper function that differed between the two applications to do the actual ticket acquisition. [11:15:01] Once again, I wish that C had closures. [11:15:37] Yeah, true. [11:15:47] Or you could just let klog get a TGT. [11:16:06] I'm not sure how vitally important it is that klog do an AS_REQ as opposed to using an in-memory ticket cache and doing a TGS_REQ. [11:16:45] I guess if there's a site that's set whatever-that-flag-is on the KDC that means that a principal can only be used with AS_REQs [11:16:46] I could manufacture a situation in which one cares, but it seems pretty artificial. [11:16:54] Not that I can think why you'd want to do that ... [11:17:00] Also, you really don't want to be doing DES AS_REQs anyway. [11:17:12] You don't really want to be doing DES. [11:17:28] Yeah, but getting a DES service ticket via an AES TGS_REQ isn't as bad. [11:18:04] (It did occur to me that with some craftiness you could negotiate a session key using something other than DES, and then use derivation to keep AFS happy) [11:18:31] So you'd have no DES principals in your KDC, and some happy auditors, but not actually change anything on the wire beyond the token format. [11:22:00] sure, but, happy auditors has value [11:24:17] That would not make our auditors happy. [11:24:22] Dunno how much it would help with others. [11:41:02] --- dev-zero@jabber.org has become available [11:57:21] --- dev-zero@jabber.org has left [11:57:33] --- dev-zero@jabber.org has become available [12:23:09] --- Kevin Sumner has left [12:29:07] --- dev-zero@jabber.org has left [13:06:35] What's the name of the kernel config setting that has to be enabled for keyring support? [13:06:49] On Linux? [13:07:01] CONFIG_KEYS I think. Lemme check. [13:07:12] Hm, oaky, then that doesn't explain what I'm seeing. [13:07:22] I have a system where the AFS PAG creation call succeeds, but I have no PAG. [13:07:44] Yup, CONFIG_KEYS [13:07:47] I get a high-numbered group, but no keyring. [13:07:51] CONFIG_KEYS is enabled. [13:08:04] From PAM, or from the command line? [13:08:16] corn13:/boot# pagsh \h:/boot$ id uid=0(root) gid=0(root) groups=0(root),1106606838 \h:/boot$ keyctl show Session Keyring -3: key inaccessible (Required key not available) [13:08:36] Okay. That's wierd. [13:08:41] Yeah. No kidding. [13:08:52] Kernel version? [13:08:57] It's working fine on some other systems with identical kernel, identical configuration, but not on this one. [13:09:07] Custom-built patched 2.6.31.4 [13:09:13] Nothing in dmesg? There are quotas on number of keys that can be allocated. [13:09:13] Which is why I suspected kernel configuration. [13:09:36] Selinux / Apparmour / similar nonsense? [13:09:37] No, there are a few messages about AFS tokens expiring, but nothing about keys. [13:09:43] No SELinux. [13:09:58] It is Ubuntu, so maybe apparmor? [13:10:23] Well, the kernel is built with SELinux support. [13:10:25] That's possible, yes. [13:10:26] But we don't have it enabled. [13:10:29] Okay. [13:11:17] Hm, how could I tell that apparmor was doing something weird? [13:11:37] Ah, hm. [13:11:43] I don't know. SELinux logs the wierdness. [13:11:52] I get a PAG if I log in normally as a regular user and then run pagsh. [13:11:52] Good hm or bad hm? [13:12:01] But pam-afs-session isn't creating a PAG. [13:12:10] This is really strange. [13:12:24] corn13:~> keyctl show Session Keyring -3 --alswrv 11857 0 keyring: _ses corn13:~> id uid=11857(rra) gid=0(root) groups=0(root) corn13:~> pagsh $ keyctl show Session Keyring -3 --alswrv 11857 0 keyring: _ses.30303 758198354 ----s--v 0 0 \_ afs_pag: _pag $ id uid=11857(rra) gid=0(root) groups=0(root),1106606846 [13:12:56] No pam_keyring anywhere in our configuration. [13:13:00] Is the machine busy? [13:13:05] Yes. It's a timeshare system. [13:13:09] Load average of 7. [13:13:15] I bet you've hit the keyring quota limit. [13:13:23] Does that just not get logged anywhere? [13:13:31] Let me go read some kernel source. [13:14:59] The kernel returns EDQUOT [13:15:17] So I should get a failure from the AFS system call to create a PAG, yes? [13:15:57] We cast the error away. [13:16:12] Er. [13:16:13] So no, it'll never reach you. The Linux kernel module throws away the error. [13:16:17] Oh, fun. [13:16:24] So basically if that's happening, I have no idea. [13:16:31] But pagsh is working and creating a PAG. [13:16:34] Consistently. [13:16:39] But pam-afs-session is failing, consistently. [13:16:52] Does pam-afs-session run as the user, or as root? [13:16:59] root. [13:17:04] Yeh. That's the problem. [13:17:05] but pagsh runs as the user. [13:17:06] Bingo. [13:17:13] Per-user quota. [13:17:14] Awesome. [13:17:18] How do I increase the quota? [13:17:25] change the value of /proc/sys/kernel/keys/root_maxkeys [13:17:42] Holy shit, 200? [13:17:46] Gah. [13:18:55] Given we're in the kernel, we could just do the allocation without counting it against the quota ... [13:19:36] Is this keys.root_maxkeys for sysctl? [13:19:49] I don't recall how you map /proc to sysctl settings. [13:20:15] --- deason has left [13:21:16] --- deason has become available [13:22:11] kernel.keys.root_maxkeys, I think. Lemme check. [13:22:35] Yup. [13:22:36] That's it. [13:22:40] Thank you, Simon! [13:22:43] We should document this somewhere. [13:22:58] Well, we should document it. [13:23:15] We shoudl fix the code (in 1.5, at least) so that failure to install the keyring causes setpag to fail. [13:23:35] We should perhaps consider allocating the keyring outside of the quota (not sure about this one...) [13:25:09] You fancy opening a bug? If we ask nicely, Marc might take a look at this - he was the last one playing around with this code (not that the bug is is - it's been there for ages) [13:26:07] Sure, I'll open a bug. [13:26:37] thanks [13:27:17] --- deason has left [13:27:51] --- deason has become available [13:29:47] RT 126230 [13:31:33] Thanks [13:32:55] --- deason has left [13:35:26] What's actually more interesting is that whatever we're half doing is breaking later runs of pagsh. We're obviously half managing to install a key ring. Which is interesting. [13:35:46] Oh, the key inaccessible thing? [13:35:53] Yeh. [13:36:03] You also get that if you have a PAG that predates unloading and reloading the AFS kernel module. [13:36:04] And the fact that pagsh run as the user doesn't then work. [13:44:01] Yeh. This keyring code is funky. [13:44:23] The session keyring is allocated as the current user, and must fit into the current user's quota. [13:44:45] The key which holds the PAG is allocated as root, and counts towards roots quota, but may overrun it. [13:47:48] If 1.5.70 is going to ship soon, I'd like to see f89c0feae89e9a255afb8a7f08995412a3f1b79 backed out before we do so. It's a security issue - that change exposes data in drop boxes that would previously have been hidden by the cache manager. [14:14:31] --- mdionne has become available [14:19:17] --- dev-zero@jabber.org has become available [14:23:48] --- meffie has left [14:45:41] --- dev-zero@jabber.org has left [14:55:03] 1.5.70 will ship probably tonight. that is backed out. we should probably also back out the other thing for now, until we have a better handle on how to really fix it [14:55:36] The afs_AccessOK thing? [14:55:49] in getattr, I mean? [14:56:47] yes, back out the security fix which is, not so fixy [14:57:15] I think we should pull it from 1.4.x before we ship the next rc. [14:57:51] I'm happy to leave it in head for now. I think I have a fix in mind (the thing we talked about earlier, where we use a flag to relax afs_AccessOK's behaviour just for getattr) [14:57:53] well, that too. but i'm thking more likepulling it from 1.5.70 now [14:58:08] put it back for .71 once we have a fix [14:59:10] Yeh. Okay. [15:36:41] --- bpoliakoff has left [15:53:01] --- mdionne has left [16:14:18] --- Jeffrey Altman has become available [16:28:37] --- Jeffrey Altman has left [16:54:11] --- summatusmentis has left [17:07:00] --- mdionne has become available [17:10:39] --- Russ has left: Disconnected [17:30:59] --- Russ has become available [17:42:44] Ok, so after massaging pagsh a bit I can manage to get "setpag: Disk quota exceeded" from pagsh [17:44:06] .. in the case where we've exceeded the keyring quota [17:47:24] Hm, you only had to modify pagsh? [17:50:08] no, also had to not ignore the error from install_session_keyring [17:50:39] Oh, okay. [17:51:07] but it's not clear to me how you interface with setpag from your pam-afs-session code [17:51:52] I basically do the same thing that libsys does. [17:52:09] So if the AFS syscall returns an error, I'll see it. [17:53:24] ok, but in the case of pagsh I had to do some tweaking - it assumes the error is coming in errno, but that's not the case if we're doing an ioctl. and it only checks for -1 [17:57:24] I think I do the right thing there. [17:57:37] another easier workaround is to make the session keyring not check quotas at all (by passing it a flag) - but like Simon said I'm not sure that's the right thing to do [17:59:33] BTW /proc/key-users will show you the current quotas and usage for all users [18:01:23] Oh, cool. [18:05:30] --- dwbotsch has left [18:05:56] --- dwbotsch has become available [18:13:19] I pushed a patch to gerrit that preserves the error from install_session_keyring. Is this something you can test with pam-afs-session? [18:15:16] Yes, although probably not for the next few days. [18:19:50] No problem. I'll push the pagsh bits separately. [18:37:43] --- shadow@gmail.com/owl81CD615B has left [19:11:04] --- kula has left [19:13:31] --- mdionne has left [19:57:47] --- kula has become available [20:43:02] --- dev-zero@jabber.org has become available [20:43:18] --- dev-zero@jabber.org has left [20:43:30] --- dev-zero@jabber.org has become available [21:07:31] --- jaltman has left: Replaced by new connection [21:07:32] --- jaltman has become available [21:10:17] --- dev-zero@jabber.org has left [21:45:56] --- kula has left [22:28:59] --- kula has become available [23:07:14] --- Russ has left: Disconnected