Bug 786993

Summary: sssd and kerberos should change the default location for create the Credential Cashes to /run/usr/USERNAME/krb5cc
Product: [Fedora] Fedora Reporter: Daniel Walsh <dwalsh>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: bfields, jhrozek, jlayton, nalin, sbose, sgallagh, ssorce, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: nfs-utils-1.2.5-14.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 786957
: 796429 (view as bug list) Environment:
Last Closed: 2012-05-08 00:11:51 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 786957    
Bug Blocks: 796429, 796430    

Description Daniel Walsh 2012-02-02 15:43:55 EST
+++ This bug was initially created as a clone of Bug #786957 +++

I know we are late for this as a security feature, but I have been running with this for a while and I think it is the right thing to do.

Change sssd default to put the cc file in /run/user.  If this is accepted we will have to change rpc.gssd to look in this new location.

If you want I will write up a feature page for this.

--- Additional comment from sgallagh@redhat.com on 2012-02-02 13:54:31 EST ---

It's probably too late for a feature submission, but can you open a dialog with the rpc.gssd folks about changing this? Find out whether it can be done within the F17 alpha timeframe (read: by Feb 13).
Comment 1 Daniel Walsh 2012-02-02 15:44:31 EST
Steve how much work would it be to get rpc.gssd to search /run/user/USERNAME/
before searching /tmp?
Comment 2 Nalin Dahyabhai 2012-02-02 17:09:17 EST
As Stephen and Simo have noted elsewhere, when we do that we might as well have SSSD drop the unique-suffix-via-mkstemp() logic, as it's only being done to avoid a DoS that's possible in a shared /tmp, and not to ensure that ccaches are per-session.

At any rate, rpc.gssd would want to be able to search the ccache with a name along the lines of "DIR:/run/user/$LOGIN/blahblah" or "FILE:/run/user/$LOGIN/blahblah", depending on whether the agreed-upon location was a directory or a file (the exact name under /run/user/$LOGIN is not set yet).  The libraries should know the specifics of how to deal with the contents of the ccache, so long as rpc.gssd tells them to look there.
Comment 3 Steve Dickson 2012-02-03 11:39:19 EST
(In reply to comment #1)
> Steve how much work would it be to get rpc.gssd to search /run/user/USERNAME/
> before searching /tmp?
Changing the default path probably will not be too bad but getting the user name might be a bit time consuming since uids are passed up from the kernel. Doing that uid to username conversion very time consuming... 

/run/usr/<uid>/ would be better from rpc.gssd's perceptive
Comment 4 Stephen Gallagher 2012-02-03 15:18:25 EST
This would be very easy to accomplish from SSSD's perspective, but I defer to Dan to tell us how feasible this is from SELinux's (and systemd's) point of view. I got the impression that /var/run/user/username was automatically created (and its permissions managed) by systemd.
Comment 5 Simo Sorce 2012-02-03 18:49:11 EST
(In reply to comment #3)
> (In reply to comment #1)
> > Steve how much work would it be to get rpc.gssd to search /run/user/USERNAME/
> > before searching /tmp?
> Changing the default path probably will not be too bad but getting the user
> name might be a bit time consuming since uids are passed up from the kernel.
> Doing that uid to username conversion very time consuming... 
> 
> /run/usr/<uid>/ would be better from rpc.gssd's perceptive

Maybe we can have a symlink with the userid.
Comment 6 J. Bruce Fields 2012-02-06 07:58:14 EST
The kernel can't pass up any uids, all it has to pass up is a gss init_sec_context token, which svcgssd uses the gss/krb5 libraries to turn into some kind of gss name, which is mapped to numeric id's by libnfsidmap--see nfs-utils/utils/gssd/svcgssd_proc.c:get_ids().  (I don't really know if that's the best way to do it, but that's how it works right now.)

So if there's an easy way to map the gss name to the right form then getting the username shouldn't be too bad....

But it still might be simplest if we could continue doing the lookup by id.
Comment 7 Simo Sorce 2012-02-06 08:27:39 EST
Bruce,
I think you are describing the case of a NFS server.
Ccaches are used in the case of an NFS client. In that case the uid is the only information the kernel has about the process trying to access a specific mount point.
In gss-proxy I can do the uid->name lookup (which is very fast with either nscd or sssd+memcache patches so I don't think you should worry too much about the speed of that lookup.

HTH,
Simo
Comment 8 J. Bruce Fields 2012-02-06 08:45:43 EST
(In reply to comment #7)
> Bruce,
> I think you are describing the case of a NFS server.
> Ccaches are used in the case of an NFS client. In that case the uid is the only
> information the kernel has about the process trying to access a specific mount
> point.

Bah, you're right, sorry for not following carefully!

> In gss-proxy I can do the uid->name lookup (which is very fast with either nscd
> or sssd+memcache patches so I don't think you should worry too much about the
> speed of that lookup.

OK.
Comment 9 Fedora Update System 2012-02-22 09:36:22 EST
sssd-1.8.0-5.fc17.beta3 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/sssd-1.8.0-5.fc17.beta3
Comment 10 Stephen Gallagher 2012-02-22 09:41:58 EST
Sorry, selected the wrong BZ for this update. It has now been correct.

But you're at least now aware that the SSSD side of this change is now in updates-testing. Please look into the nfs-utils changes ASAP.
Comment 11 Fedora Update System 2012-03-27 11:49:04 EDT
nfs-utils-1.2.5-14.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2012-4479/nfs-utils-1.2.5-14.fc17
Comment 12 Simo Sorce 2012-03-27 12:18:07 EDT
Wasn't this supposed to go only in rawhide ?
Comment 13 Fedora Update System 2012-04-21 17:02:58 EDT
Package nfs-utils-1.2.5-14.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.5-14.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4479/nfs-utils-1.2.5-14.fc17
then log in and leave karma (feedback).
Comment 14 Stephen Gallagher 2012-04-21 17:24:27 EDT
This change shouldn't be pushed to F17, it should only be in Rawhide. It's too potentially disruptive.
Comment 15 Fedora Update System 2012-05-08 00:11:51 EDT
nfs-utils-1.2.5-14.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.