This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 796429

Summary: sssd and kerberos should change the default location for create the Credential Caches to /run/usr/USERNAME/krb5cc
Product: [Fedora] Fedora Reporter: Stephen Gallagher <sgallagh>
Component: krb5Assignee: Roland Mainz <rmainz>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: asn, bfields, dpal, dwalsh, dwmw2, jhrozek, mkosek, nalin, nathaniel, rharwood, rmainz, sbose, sgallagh, ssorce, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 786993
: 796430 (view as bug list) Environment:
Last Closed: 2015-02-17 09:08:06 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 786957, 786993    
Bug Blocks: 796430, 796910    

Description Stephen Gallagher 2012-02-22 16:18:44 EST
Cloning to krb5. We want to change the default location for tools such as kinit to /run/user/<username>/krb5cc as well.


+++ This bug was initially created as a clone of Bug #786993 +++

+++ 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).

--- Additional comment from dwalsh@redhat.com on 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?

--- Additional comment from nalin@redhat.com on 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.

--- Additional comment from steved@redhat.com on 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

--- Additional comment from sgallagh@redhat.com on 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.

--- Additional comment from ssorce@redhat.com on 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.

--- Additional comment from bfields@redhat.com on 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.

--- Additional comment from ssorce@redhat.com on 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

--- Additional comment from bfields@redhat.com on 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.

--- Additional comment from updates@fedoraproject.org on 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

--- Additional comment from sgallagh@redhat.com on 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 1 Fedora End Of Life 2013-04-03 12:27:51 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 2 David Woodhouse 2013-07-10 11:39:04 EDT
Is there a clone of this for samba-winbind? In Fedora 19 it still seems to be creating my krb5cc in /tmp/krb5cc_%{uid}, necessitating that I set that as the default in /etc/krb5.conf too in order for my credentials to be visible consistently.
Comment 3 Jakub Hrozek 2013-07-10 11:45:08 EDT
(In reply to David Woodhouse from comment #2)
> Is there a clone of this for samba-winbind? In Fedora 19 it still seems to
> be creating my krb5cc in /tmp/krb5cc_%{uid}, necessitating that I set that
> as the default in /etc/krb5.conf too in order for my credentials to be
> visible consistently.

I think Andreas would know the answer best.
Comment 4 Martin Kosek 2013-07-15 04:38:43 EDT
Any update from Andreas? This Bugzilla seems to be stuck.
Comment 5 Andreas Schneider 2013-07-15 05:04:06 EDT
Please create a bug for Samba, explain the change to point to the documentation which describes the new default.

Have you made this changeable via a configure options? We still need support for older distributions and other operating systems!
Comment 6 Nalin Dahyabhai 2013-07-16 15:38:08 EDT
(In reply to Andreas Schneider from comment #5)
> Please create a bug for Samba, explain the change to point to the
> documentation which describes the new default.

Okay, filed bug #985107 for tracking it.

> Have you made this changeable via a configure options? We still need support
> for older distributions and other operating systems!

Well, yes, it's a build-time option in upstream krb5, and some other packages have opted to follow suit, with the decision being made in the Fedora .spec file.  The value returned by krb5_cc_default_name() reflects the compile-time default, and can be overridden by krb5.conf configuration, so you may wish to key off of that for a runtime default.

Thanks!
Comment 7 Fedora Admin XMLRPC Client 2014-10-06 12:37:37 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora End Of Life 2015-01-09 12:01:45 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Fedora End Of Life 2015-02-17 09:08:06 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.