Re: [OpenAFS] transitive fs la?
Todd M. Lewis wrote: Derrick J Brashear wrote: On Sun, 2 Sep 2007, Adam Megacz wrote: A user's rights on a directory are effectively moot unless s/he has l permissions on every ancestor directory (up to the volume root). So you could say that the transitive acl of a directory is its acl minus permissions which cannot currently be exercised by virtue of the acls on its ancestors. I'm interested in a simple utility to print out this sort of effective acl. For bonus points, query the pts database and factor in group membership (for example, a group you belong to has l on parent and you personally have l on the directory itself). Has anybody written this already, or should I take a crack at it? You can probably use ws as a basis. See ws.c in my homedir in the andrew cell. Go ahead, knock yourself out. Just keep in mind that the volume containing the directory you're interested in may be mounted in multiple places, and while the user may not have l rights all the way up the tree from one mountpoint, she might well have them from another. For this reason, you might want to include in your results two distinct reports: whether l is available from the given directory up to the root level of the containing volume, and a separate indication of whether the user has l rights up the tree in the given path to /afs. You might also want to make some decisions before you start writing code about how this would work when run by an admin (who could see all the ACLs) vs. a generic user (who may not). One more thing. The generic user running this utility may or may not be the subject of the query. For example, I may want to check whether I have l all the way up from a given spot. Alternatively I might occasionally want to grant Doug access to some directory, but I'd need to run your utility on that directory with Doug as the subject user rather than myself to see if he can in fact get to the data. So that's three scenarios: Admin testing a directory wrt an arbitrary subject user, Joe user testing a directory wrt himself, and Joe user testing a directory wrt some other user. Or a group. Ooooh, with groups, that's, like, six scenarios. Or multiple users and/or groups at once. Gee, I didn't realize how badly I need this utility. I'll stop now, or you may never get it written. :) -- [EMAIL PROTECTED] ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] transitive fs la?
On Mon, 03 Sep 2007 01:53:15 -0400 Todd M. Lewis [EMAIL PROTECTED] wrote: Go ahead, knock yourself out. Just keep in mind that the volume containing the directory you're interested in may be mounted in multiple places, and while the user may not have l rights all the way up the tree from one mountpoint, she might well have them from another. And remember anyone can create mountpoints anywhere they have access to (including other cells if your cell is public). So, if you're using this to verify the security of something, it's really only useful up to when you hit a mount point. -- Andrew Deason [EMAIL PROTECTED] ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] OpenSSH, Kerberos and pam-afs-session on RHEL4
Hi all. I have a question about pam-afs-session, although my problem may actually be more related to Openssh and Kerberos. I installed pam-afs-session on RHEL4 and (after some PAM tinkering) it seems to work fine, provided I use pam to do the authentication rather than openssh. This means typing my password even though I've already got a ticket on my workstation. However, I would ideally like to let openssh do the authentication (ie. set GSSAPIAuthentication yes in /etc/ssh/sshd_config). The client can forward Kerberos credentials and (hopefully) pam-afs-session can turn that into a token. Is such a setup possible? In trying to set this up, I've used these settings in sshd_config: ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication yes UsePAM yes .. and /etc/pam.d/system-auth looks like this: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired /lib/security/$ISA/pam_env.so authsufficient/lib/security/$ISA/pam_unix.so likeauth nullok auth[success=ok default=1] /lib/security/$ISA/pam_krb5.so auth[default=done] /lib/security/$ISA/pam_afs_session.so program=/usr/bin/aklog debug authrequired /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so broken_shadow account sufficient/lib/security/$ISA/pam_krb5.so account sufficient/lib/security/$ISA/pam_succeed_if.so uid 100 quiet account required /lib/security/$ISA/pam_permit.so passwordrequisite /lib/security/$ISA/pam_cracklib.so retry=3 passwordsufficient/lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow passwordsufficient/lib/security/$ISA/pam_krb5.so passwordrequired /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so session required /lib/security/$ISA/pam_afs_session.so program=/usr/bin/aklog debug When I login to the machine with this configuration, I get my Kerberos ticket propagated ok, but no token, and some messages in syslog: $ klist Ticket cache: FILE:/tmp/krb5cc_10846_QyS612 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 09/03/07 17:28:42 09/03/07 19:37:42 krbtgt/[EMAIL PROTECTED] renew until 09/03/07 09:38:26 Kerberos 4 ticket cache: /tmp/tkt10846 klist: You have no tickets cached $ tokens Tokens held by the Cache Manager: --End of list-- Sep 3 17:28:42 crashburn sshd(pam_unix)[612]: session opened for user rns by (uid=0) Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: configured realm 'UNIMELB.EDU.AU' Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: flags: forwardable Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: flag: no ignore_afs Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: flag: user_check Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: flag: no krb4_convert Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: flag: warn Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: ticket lifetime: 36000 Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: renewable lifetime: 36000 Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: banner: Kerberos 5 Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: ccache dir: /tmp Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: keytab: /etc/krb5.keytab Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: afs cell: unimelb.edu.au Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: no v5 creds for user 'rns', skipping session setup Sep 3 17:28:42 crashburn sshd[612]: pam_krb5[612]: pam_open_session returning 0 (Success) Sep 3 17:28:42 crashburn sshd[612]: (pam_afs_session): pam_sm_open_session: entry (0x0) Sep 3 17:28:42 crashburn sshd[612]: (pam_afs_session): skipping tokens, no Kerberos ticket cache Sep 3 17:28:42 crashburn sshd[612]: (pam_afs_session): pam_sm_open_session: exit (success) So it seems like pam_krb5 and pam-afs-session can't find the credentials cache. I'm not sure what order things are happening in here, and what the interactions between pam, kerberos and openssh are. Seems like I've tried just about every combination of parameters for openssh and pam but no luck. (I also tried setting always_aklog as a flag to pam-afs-session, but that made no difference). I've also seen a newer version of pam_krb5 (2.2.x) which supports flags useshmem and external that look helpful, but I was hoping not to need this as I'm trying to stick as much as possible with the vendor supplied packages (RHEL4 has pam_krb5-2.1.8-1). Ultimately I'm hoping to extend this configuration
Re: [OpenAFS] transitive fs la?
Andrew Deason wrote: On Mon, 03 Sep 2007 01:53:15 -0400 Todd M. Lewis [EMAIL PROTECTED] wrote: Go ahead, knock yourself out. Just keep in mind that the volume containing the directory you're interested in may be mounted in multiple places, and while the user may not have l rights all the way up the tree from one mountpoint, she might well have them from another. And remember anyone can create mountpoints anywhere they have access to (including other cells if your cell is public). So, if you're using this to verify the security of something, it's really only useful up to when you hit a mount point. With dynroot and freelance you must assume that everyone has a mount point to every volume in every cell. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] transitive fs la?
I'm surprised at how many people mis-read Adam's message. He explicitly said the tool would walk the path only up to the volume root. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenSSH, Kerberos and pam-afs-session on RHEL4
On Sep 3, 2007, at 10:40 AM, Russ Allbery wrote: Robert Sturrock [EMAIL PROTECTED] writes: I have a question about pam-afs-session, although my problem may actually be more related to Openssh and Kerberos. I installed pam-afs-session on RHEL4 and (after some PAM tinkering) it seems to work fine, provided I use pam to do the authentication rather than openssh. This means typing my password even though I've already got a ticket on my workstation. However, I would ideally like to let openssh do the authentication (ie. set GSSAPIAuthentication yes in /etc/ssh/sshd_config). The client can forward Kerberos credentials and (hopefully) pam- afs-session can turn that into a token. Is such a setup possible? Yes, I use it all the time on Debian. However, if I remmeber correctly, RHEL 4 ships a broken sshd that runs the PAM session hooks and *then* saves the ticket cache. This is obviously broken and has been fixed in later versions of sshd, but I don't believe Red Hat has fixed it in an update. pam-afs- session can't do anything about this; at the time that it's called, no ticket cache is available because sshd hasn't written it out yet. That's correct. I believe this bug was fixed for OpenSSH 4.0+. RHEL4 ships a patched OpenSSH 3.9p1, but does not include the fix for this bug. I put a call to aklog in .bash_profile on all my RHEL boxes, as Russ suggests, though that's obviously a less than ideal arrangement. -- Ian Ward Comfort [EMAIL PROTECTED] System Administrator, Student Computing, Stanford University ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
