Hmm, I don't follow. If this is for testing only, why doesn't the test turn this on before running?

This looks like a really bad default for everything else. Or I am totally not grokking this...

See also:
Bug 961235 - Credential cache directory /run/user/0/krb5cc does not exist

(In reply to Lennart Poettering from comment #3)
> Hmm, I don't follow. If this is for testing only, why doesn't the test turn
> this on before running?
> 
First of all a bunch of tests should to be modified to all run this prior to start and we were looking for a simpler way.

But this is a wilder topic as you can see from the bug 961235, mentioned in the previous comment. This is an issue also of kerberos and users that switched by su / sudo. 

> This looks like a really bad default for everything else. Or I am totally
> not grokking this...

I'm copying here an email discussion about this topic and it would be nice if we could get a conclusion before RHEL-7 beta.

> >> 2/ Creation of directory /run/user/ID
> >>
> >> Original bugs:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=961235
> >> https://bugzilla.redhat.com/show_bug.cgi?id=967509
> >> https://bugzilla.redhat.com/show_bug.cgi?id=961510
> >> https://bugzilla.redhat.com/show_bug.cgi?id=965419
> >> https://bugzilla.redhat.com/show_bug.cgi?id=753882
> >>
> >> Description:
> >>
> >> krb5 client tools (e.g. kinit) creates temporary caches now in
> >> directory /run/user/ID, where ID is the user ID who run the
> >> process. The problem is that the directory is created on demand
> >> when the used logs in, but not all ways of login creates it.
> >> Console login and login via ssh creates the directory but su or
> >> sudo does not.
> >>
> >> On top of that there may be situations where there is no user
> >> logged in at all, and still the directory is required; like in test
> >> scenarios where test strips are launched by daemons automatically.
> >>
> > This behavior is configurable in the user session. The default
> > location was changed to be /run/user/ID, but it can be trivially
> > overridden by setting the environment variable KRB5CCNAME to some
> > other path.
> >
> > e.g. KRB5CCNAME=FILE:/var/tmp/krb5cc_0

Yes it can be, but we have 2 use cases where the current practice
matter:
1/ /run/user/0 does not exits when no real user is logged in. That
causes issues with testing. Yes, the tests could pre-create the
directory or also can alter the KRB5CCNAME, but the aim of testing is to
verify the system in state which is close to machines in production as
much as possible.
2/ su/sudo does not change KRB5CCNAME, which point to the original
user's directory. Therefore user that switches to other user with "su -"
or "sudo -i" cannot run kinit by default, for example.

> >
> >
> >> These are 2 problems but all around the directory /run/user/ID:
> >>
> >> a/ The directory /run/user/0 directory for root should be created
> >> during system installation.
> >> https://bugzilla.redhat.com/show_bug.cgi?id=967509
> > Not possible. /run/user is a tmpfs and is wiped clean at each boot. So
> > we can't put this in an RPM.
> >
> >> Like this daemons and test scripts have their cache directory; not
> >> sure if this is against any security or other policy. If not the
> >> main question is which tool should be responsible for creation, two
> >> possible candidates were found so far: * systemd
> > systemd is what creates /run/user/ID at login time, IIRC.

Yes, systemd creates it and systemd can be configured to create the
directory for a particular user automatically too:
 # loginctl enable-linger root
That's the reason why I think systemd (or anaconda, or something else?)
could configure systemd to create it for root (or maybe other users too
when the account is created).
The question is is such a pre-creation is desirable and if yes, which
component should be responsible for it.

> >
> >> * anaconda
> >>
> >> b/ su should create /run/user/$UID while login and set
> >> XDG_RUNTIME_DIR accordingly
> >> https://bugzilla.redhat.com/show_bug.cgi?id=965419 The bug above
> >> was closed due to the following systemd bug:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=753882, where is a
> >> long discussion about the capabilities of "su" and "su -". su is a
> >> commonly used tool by admins to switch users and it seems that in
> >> RHEL-7 it will dramatically reduce it's usefulness by not setting
> >> environment parameters (and also not creating the /run/user/ID dir)
> >> that admins get used to. The question is if RHEL-7 should go in
> >> this direction, i.e. reducing the the capabilities of su/sudo and
> >> thus reducing the user/admin experience. Use cases that used to
> >> work but not any longer since systemd are in bugs:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=961235
> >> https://bugzilla.redhat.com/show_bug.cgi?id=753882
> >>
> > 'su' was never supposed to set env vars, as far as I understood
> > things. It was supposed to inheret them from the calling application
> > and change only the user ID that was executing commands. I'll need to
> > read through those bugs more closely before commenting further.
> >
> >
> >
> >> c/ sudo should create /run/user/$UID while login
> >> https://bugzilla.redhat.com/show_bug.cgi?id=961510 This the same as
> >> above just for sudo; including here for completeness.
> >>
> >
> > Part of the problem with doing this is that, without a login session,
> > we don't know when it's safe to clean up the /run/user/ID directory
> > (and reclaim space for the tmpfs). I'd argue that we might want to
> > just have su and sudo just set KRB5CCNAME to a mkstemp() location, use
> > the cache for the operation and remove it when the operation is complete.

The main questions here are:

* Should the /run/user/0 directory be pre-created at installation time? If yes by whom? If not, why not?

* Should su/sudo create /run/user/<ID> or set KRB5CCNAME to valid tmp directory (so kinit works by default after su - <newuser>)?

(In reply to Patrik Kis from comment #7)
> The main questions here are:
> 
> * Should the /run/user/0 directory be pre-created at installation time? If
> yes by whom? If not, why not?

It can't be created at installation time since /run is defined to be a tmpfs.  It could be trivially created at bootup by a systemd-tmpfiles rule though.

But why is uid 0 special here?  Is it just because your Kerberos tests run as root (eww?)  Or do you really mean /run/user/<uid> generally?

> * Should su/sudo create /run/user/<ID> or set KRB5CCNAME to valid tmp
> directory (so kinit works by default after su - <newuser>)?

Hm, "su -" should unset KRB5CCNAME, and I don't see that variable in the default sudo env_keep.  So after either using "su -" or sudo, kerberos should reset to the defaults.

Is it just that 'su -' (or 'su - <someuser>') doesn't create a session, which causes the directory to get created normally? I think fixing that makes more sense than precreating directories.

(In reply to Colin Walters from comment #8)
> (In reply to Patrik Kis from comment #7)
> > The main questions here are:
> > 
> > * Should the /run/user/0 directory be pre-created at installation time? If
> > yes by whom? If not, why not?
> 
> It can't be created at installation time since /run is defined to be a
> tmpfs.  It could be trivially created at bootup by a systemd-tmpfiles rule
> though.

You are right. What we need is to have the directory prepared after the system boots. Why I mentioned install time is that systemd have the linger option and if that is enabled during install time, the directory is created during every boot.

> 
> But why is uid 0 special here?  Is it just because your Kerberos tests run
> as root (eww?)  Or do you really mean /run/user/<uid> generally?

I know, this is nasty and it should be more general and of course more clear solution would be to create the directory for every user (really everything in /etc/passwd) during boot time.
Is that possible? I'd be really happy.

> 
> > * Should su/sudo create /run/user/<ID> or set KRB5CCNAME to valid tmp
> > directory (so kinit works by default after su - <newuser>)?
> 
> Hm, "su -" should unset KRB5CCNAME, and I don't see that variable in the
> default sudo env_keep.  So after either using "su -" or sudo, kerberos
> should reset to the defaults.

Maybe I didn't express myself correctly; please see the following scenario:

[root@rhel7 ~ ]# su - test
Last login: Tue Jul 16 17:22:38 CEST 2013 on pts/1
[test@rhel7 ~]$ kinit Administrator
kinit: Credential cache directory /run/user/1000/krb5cc does not exist while getting default ccache
[test@rhel7 ~]$ ll /run/user/
total 0
drwx------. 3 root root 60 Jul 16 15:57 0
[test@rhel7 ~]$ env |grep KRB
[test@rhel7 ~]$ 

If I do "sodo -u test -i" it is the same.
One would expect that this scenario works.

(In reply to Patrik Kis from comment #6)
> Yes it can be, but we have 2 use cases where the current practice
> matter:
> 1/ /run/user/0 does not exits when no real user is logged in. That
> causes issues with testing. Yes, the tests could pre-create the
> directory or also can alter the KRB5CCNAME, but the aim of testing is to
> verify the system in state which is close to machines in production as
> much as possible.

This request really makes no sense, creating /run/user/0 at boot unconditionally is just wrong. The lifecycle of that dir is bound to the user being logged in at least once. The whoe reason we introduced the dir is that it has these lifecycle guarantees. It's really wrong to break that just because of your artificial test.

If you want this to be realistic why don't you run your tests inside a proper session? That way you will get /run/user/0 for free, and you are *actually* running like in a production system.

Sorry, but this really doesn't make any sense to me, at all.

(In reply to Lennart Poettering from comment #11)
> (In reply to Patrik Kis from comment #6)
> > Yes it can be, but we have 2 use cases where the current practice
> > matter:
> > 1/ /run/user/0 does not exits when no real user is logged in. That
> > causes issues with testing. Yes, the tests could pre-create the
> > directory or also can alter the KRB5CCNAME, but the aim of testing is to
> > verify the system in state which is close to machines in production as
> > much as possible.
> 
> This request really makes no sense, creating /run/user/0 at boot
> unconditionally is just wrong. The lifecycle of that dir is bound to the
> user being logged in at least once. The whoe reason we introduced the dir is
> that it has these lifecycle guarantees. It's really wrong to break that just
> because of your artificial test.
> 
> If you want this to be realistic why don't you run your tests inside a
> proper session? That way you will get /run/user/0 for free, and you are
> *actually* running like in a production system.
> 
> Sorry, but this really doesn't make any sense to me, at all.

Ok, I take it. The tests can be modified of course (even if that takes some time, but I agree, that at the end they will be more close to production systems). I just wanted to check the possibilities, if creation of that directory make sense or it is desirable.

But the second problem about su and sudo is still open and as far as I know it is also systemd related (coorect me if I'm wrong). In the ancestor Fedora bugs (bug 961510 and bug 965419) it was indicated that it is related the problem in bug 753882.
What is not working is at the end of comment 10 in this bug. That scenario was working out of the box in RHEL-6 and one would expect work it again and it can be considered as regression.

I accepted that the directory is not created at the boot time. The second part of this bug, however, still remains and it is considered to be a regression against RHEL-6. It would be nice to have decision how and where should it be fixed before RHEL-7 beta.
All details can be found in the comment 10 and comment 11.

I am working with the Kerberos, SSSD and systemd engineers to come up with a solution. Currently the recommendation that I am pursuing is as follows:

We modify systemd as Simo wrote above, so that it is guaranteed to
always create /run/user any time pam_systemd is called in the session
phase (and handle it in the appropriate way when pam_session_close is
called). This will address all cases where a full login is performed
(i.e. 'su -' but not 'su')


In the longer term, we will also discuss ways that systemd could provide an interface that could be called in order to generate this directory on-demand, but that will take some time and must be done carefully, since improper implementation could lead to privilege escalation bugs.

(In reply to Stephen Gallagher from comment #14)
> We modify systemd as Simo wrote above, so that it is guaranteed to
> always create /run/user any time pam_systemd is called in the session
> phase (and handle it in the appropriate way when pam_session_close is
> called). This will address all cases where a full login is performed
> (i.e. 'su -' but not 'su')

We should also make sure that everything that starts a user session in the conceptional sense does so involving PAM, calling pam_open_session.  One such example is suexec from Apache httpd.  Postfix needs to change the way it spawns processes under different user IDs, too.

In the long term, availability of the /run/user/ID directory will benefit other libraries and applications, not just Kerberos. (We regularly have to patch unsafe use of /tmp for various caches, often disabling them completely.)

So, the kerberos team has now found a much better solution by using the kernel keyring for storing kerberos credentials.

This leaves the "sudo -s" and "su -l" case. Which I'd be OK with adding a bit of code that in these case (and only these cases, i.e. not for normal sudo or normal su) we open a true new logind session from an existing one. It isn't pretty though as the session definition will not be the same on all layers anymore (since the audit session won't change in that case).

So, anyway, closing this for now, since a better solution for the specific usecase has been found. I'd be fine though if a new RFE bug is created asking for an explicit new session for "sudo -s" and "su -l".

(In reply to Lennart Poettering from comment #16)
> So, the kerberos team has now found a much better solution by using the
> kernel keyring for storing kerberos credentials.
> 
Can you provide more detail about this solution?
Does it means that after 'su -l' and  it will be possible to obtain kerberos tickets?
Is there a bug where this feature is tracked and ideally can be verified?

(In reply to Patrik Kis from comment #17)
> (In reply to Lennart Poettering from comment #16)
> > So, the kerberos team has now found a much better solution by using the
> > kernel keyring for storing kerberos credentials.
> > 
> Can you provide more detail about this solution?
> Does it means that after 'su -l' and  it will be possible to obtain kerberos
> tickets?
> Is there a bug where this feature is tracked and ideally can be verified?

We've got a tracking bug for this in BZ #991169

(In reply to Stephen Gallagher from comment #18)
> (In reply to Patrik Kis from comment #17)
> > (In reply to Lennart Poettering from comment #16)
> > > So, the kerberos team has now found a much better solution by using the
> > > kernel keyring for storing kerberos credentials.
> > > 
> > Can you provide more detail about this solution?
> > Does it means that after 'su -l' and  it will be possible to obtain kerberos
> > tickets?
> > Is there a bug where this feature is tracked and ideally can be verified?
> 
> We've got a tracking bug for this in BZ #991169

Sorry, I should have mentioned before clicking "save" that this is the tracker for the Kerberos changes. I'll leave it to Lennart to point out the 'su -l' BZ.

As far as the new session in case of "su -l"/"sudo -s" concerns, if the new method of kerberos ccache creation ensures itself that kinit will work after su -l/sudo -s, I do not need an explicit new session. I personally do not know any other use case.

@Stephen, can you please confirm that with ccache kerberos changes (bug 991169) it will be possible to obtain kerberos tickets as new user?

It's hard to give a clear answer to this. The problem with 'su' and 'sudo' is that it doesn't always provide a clean-room environment. It's somewhat ambiguous when doing (as user1) 'sudo <action>' (as user2) if you would want the service to be using the Kerberos credentials from user1 or user2. I'm not sure what the right answer is there.

Currently, I think our plan is that we will normally use the caller's credentials unless they do the equivalent of 'su - <username>', at which point they should be using the target user's credentials. That's the best compromise I can come up with.

This bug constantly hits libvirt and libguestfs users on RHEL 7.
What can be done to fix it?

(In reply to Richard W.M. Jones from comment #22)
> This bug constantly hits libvirt and libguestfs users on RHEL 7.
> What can be done to fix it?

I believe we need to change the freedesktop.org specification first and then adjust the behavior.  I'm strongly in favor because it will eventually allow us to remove the XDG_RUNTIME_DIR fallback code from applications.

Hey folks, first of all sorry for bumping this. I recently got this problem and this was one of the first hits on google. I just want to add a comment for anybody reaching this in the future with a solution that worked really well for me:

   machinectl shell --uid=username

that works in RHEL / CentOS 8 (stream) and should on any other distro with modern components. Not sure about RHEL, didn't test it there yet.

Machinectl is quite amazing and the use case to open a user session on the same host image is not as popular / easy to find on google as it should be, so I hope this helps spreading it.