Bug 796430

Joe,
just to give you some context, this bug has been cloned for mod_auth_kerb because with the new s4u2proxy features it now needs to create a credential cache when that feature is enabled.

So what mod_auth_kerb packages should is to drop a configuration file in /etc/tmpfiles.d similar to what httpd already does.

The tmpfile for mod_auth_kerb should create a directory in /var/run/user/apache, owned by the apache user and with permissions 700

HTH.

Thanks for the heads up.  When you say a directory "in" /var/run/user/apache, do you mean that directory name itself, i.e. the tmpfile drop-in should be:

d /var/run/user/apache 700 apache apache

There is already a hard-coded reference to the cred cache filename used in mod_auth_kerb, separate from the s4u2proxy patch, does that need to change also?

   ccname = apr_psprintf(r->pool, "FILE:%s/krb5cc_apache_XXXXXX", P_tmpdir);
   fd = mkstemp(ccname + strlen("FILE:"));

should that code be using some library interface rather than generating the filename itself?

(In reply to comment #2)
> Thanks for the heads up.  When you say a directory "in" /var/run/user/apache,
> do you mean that directory name itself, i.e. the tmpfile drop-in should be:
> 
> d /var/run/user/apache 700 apache apache

Yes, the directory is named after the user.

> There is already a hard-coded reference to the cred cache filename used in
> mod_auth_kerb, separate from the s4u2proxy patch, does that need to change
> also?
> 
>    ccname = apr_psprintf(r->pool, "FILE:%s/krb5cc_apache_XXXXXX", P_tmpdir);
>    fd = mkstemp(ccname + strlen("FILE:"));
> 
> should that code be using some library interface rather than generating the
> filename itself?

No the reason why you generate a filename is that this is a separate credential cache that contains the delegated credentials from the user and need to differ at each invocation. If you relied on the library you'd overwrite apache own credentials.

However I think it may make sense to change the code to use /var/run/user/apache as the P_tmpdir.
This is not strictly required. In F17 httpd is configured to use a private tmp by default so using /tmp is not terribly bad, but using [/var]/run is a tmpfs and that means the ccaches are all wiped out at reboot so there is no risk of leaving credentials around on hard resets.

Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=714ec4bff69608160f9155b7a634e0630ec05f41
Package: mod_auth_kerb-5.4-13.fc18
Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=316630

Sorry, my script lied, this is not fixed in -13.

BTW this is filed against Raw Hide but there are mentions of f17 above, I presume this is required in f17?

Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=7954e0c420f9e453866349e893f5e95085c611fb
Package: mod_auth_kerb-5.4-14.fc18
Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=318422

Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=87d22fe3b89d479192f61bc67048ad1a0f6037fe
Package: mod_auth_kerb-5.4-14.fc17
Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=318430

No, sorry. The original plan was to do this for F17, but when we became aware that it touched too many packages, we deferred it to F18 so we'd have time to get it right.

So this is NOT the default location in F17. That remains /tmp/krb5cc_UID[_XXXXXX]


As an aside, please also be aware of https://fedoraproject.org/wiki/Features/KRB5DirCache (I'll be opening a bug against mod_auth_kerb soon to handle this).

OK, thanks Stephen.  It doesn't seem harmful to have the tmpfile in the f17 branch too so I won't bother reverting that.

This patch is causing httpd to core dump. I'm testing with IPA:

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31
31              movdqu  (%rdi), %xmm1
(gdb) where
#0  __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31
#1  0x00007f1757b51e9e in apr_pstrcat () from /lib64/libapr-1.so.0
#2  0x00007f174c9e6dd9 in create_krb5_ccache (kcontext=0x7f1759fc9890,
    r=r@entry=0x7f175a100840, princ=0x7f175a088c20, 
    ccache=ccache@entry=0x7fff98e67330, 
    conf=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
    at src/mod_auth_kerb.c:895
#3  0x00007f174c9e9a01 in store_gss_creds (delegated_cred=0x7f175a0d9d80, 
    princ_name=<optimized out>, r=0x7f175a100840, conf=<optimized out>)
    at src/mod_auth_kerb.c:1220
#4  authenticate_user_gss (negotiate_ret_value=<synthetic pointer>, 
    auth_line=0x7f175a1021c9 "", conf=0x7f1759d826d8, r=0x7f175a100840)
    at src/mod_auth_kerb.c:1790
#5  kerb_authenticate_user (r=0x7f175a100840) at src/mod_auth_kerb.c:2009
#6  0x00007f1758e83770 in ap_run_check_user_id ()
#7  0x00007f1758e86450 in ap_process_request_internal ()
#8  0x00007f1758ea1598 in ap_process_async_request ()
#9  0x00007f1758ea187f in ap_process_request ()
#10 0x00007f1758e9e125 in ?? ()
#11 0x00007f1758e96250 in ap_run_process_connection ()
#12 0x00007f174ea5d727 in ?? () from /etc/httpd/modules/mod_mpm_prefork.so
#13 0x00007f174ea5d96c in ?? () from /etc/httpd/modules/mod_mpm_prefork.so
#14 0x00007f174ea5e7ae in ?? () from /etc/httpd/modules/mod_mpm_prefork.so
#15 0x00007f1758e736ae in ap_run_mpm ()
#16 0x00007f1758e6d17a in main ()

(In reply to comment #8)
> No, sorry. The original plan was to do this for F17, but when we became
> aware that it touched too many packages, we deferred it to F18 so we'd have
> time to get it right.
> 
> So this is NOT the default location in F17. That remains
> /tmp/krb5cc_UID[_XXXXXX]
> 
> 
> As an aside, please also be aware of
> https://fedoraproject.org/wiki/Features/KRB5DirCache (I'll be opening a bug
> against mod_auth_kerb soon to handle this).

Steven we do not need to use a DIR: cache type for mod_auth_kerb, unless it will start handling multiple credentials, a FILE: ccache is sufficient for apache

I'm not sure why but it seems to be the apr_pstrcat() that is causing the grief. I replaced it with apr_psprintf and replaced FILE: with FILE:%s and it works.

Well, it works to a point. httpd does not have write permissions on /run/httpd so the request still fails, it can't create the ccache. chmod g+w makes it work but this doesn't quite seem like the right thing to do.

Rob, oops - the pstrcat call needs a , NULL at the end.  I've fired off a build.

I missed your other comment.  Hmmm, my patch was doubly wrong.  I think it should hard-code /run/user/apache.

Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=22f4ad25e5dcd209069dd4100704edc94ac8a691
Package: mod_auth_kerb-5.4-15.fc18
Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=324979

Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=7ec72fbee571525d4ea48d98987c07e576462aaa
Package: mod_auth_kerb-5.4-16.fc18
Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=324983

Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=5fadd09e52508859eed9584b4e1c1c68e04cb21d
Package: mod_auth_kerb-5.4-16.fc17
Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=324987

Rob, can you try the -16 build linked above?  /run/user/apache should be created with the correct permissions and should be used for the cache.

Seems to be working, initial testing looks good. Thanks for the quick turnaround.

mod_auth_kerb-5.4-16.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mod_auth_kerb-5.4-16.fc17

Great, thanks for testing it out.  I've submitted that package as an update for f17.

I had only tested the F-18 build. I'm getting a permission denied on F-17:

[Wed Jun 13 11:54:58 2012] [error] [client 192.168.166.44] mkstemp() failed: Permission denied, referer: https://pinto.example.com/ipa/xml

strace says:

open("/run/user/apache/krb5cc_apache_fYlDXR", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)

Permissions look ok

# ls -ld /run/
drwxr-xr-x. 28 root root 1080 Jun 13 11:53 /run/
# ls -ld /run/user
drwxr-xr-x. 6 root root 120 Jun 13 12:01 /run/user
# ls -ld /run/user/apache/
drwx------. 2 apache apache 40 Jun 13 11:19 /run/user/apache/

I didn't see any SELinux errors but as a goof I set to permissive mode and it started working. Still no AVCs logged so I set back to enforcing and it is still working. I'm a bit stumped.

If you remove the file altogether and maybe remove /run/user/apache, does the SELinux block it again.  

I would figure the problem might be related to the labeling of /run/user/apache

It appears to be ok:

# ls -ldZ /run/user/apache
drwx------. apache apache system_u:object_r:user_tmp_t:s0  apache

I tried again and it was failing again in enforcing mode but I wasn't seeing any logging in audit. I put it into permissive mode and now I see these:

type=AVC msg=audit(1339704357.328:2128): avc:  denied  { write } for  pid=27635 comm="httpd" name="apache" dev="tmpfs" ino=190674 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
type=AVC msg=audit(1339704357.328:2128): avc:  denied  { add_name } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
type=AVC msg=audit(1339704357.328:2128): avc:  denied  { create } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1339704357.328:2128): avc:  denied  { open } for  pid=27635 comm="httpd" path="/run/user/apache/krb5cc_apache_Ka3hGH" dev="tmpfs" ino=207179 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1339704357.338:2129): avc:  denied  { remove_name } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" dev="tmpfs" ino=207179 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
type=AVC msg=audit(1339704357.338:2129): avc:  denied  { unlink } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" dev="tmpfs" ino=207179 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1339704357.526:2130): avc:  denied  { setattr } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" dev="tmpfs" ino=207186 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file

Right we need the /run/user/apache directory labeled as httpd_tmp_t or something else, since we currently label /run/user as user_tmp_t, we need a transition for httpd to create apache labeled httpd_tmp_t.

Fixed in selinux-policy-3.10.0-131.fc17

Package mod_auth_kerb-5.4-16.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 mod_auth_kerb-5.4-16.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9427/mod_auth_kerb-5.4-16.fc17
then log in and leave karma (feedback).

(In reply to comment #18)
> Rob, can you try the -16 build linked above?  /run/user/apache should be
> created with the correct permissions and should be used for the cache.
Incorrect. /run/user is tmpfs so you have to use /etc/tmpfiles.d entry to create the directory.

And given that /run/user/apache is for all httpd users, /run/user/apache should be created and owned by httpd package, not mod_auth_kerb.

I'm turning this bug back to NEW state.

Please remove ownership of /run/user/apache from mod_auth_kerb, it does not help at all.

I verified that with selinux-policy-3.1.0-132.fc17 and small change to /etc/tmpfiles.d/httpd.conf I'm able to use IPA on F17 again:

# ipa user-find
ipa: ERROR: cannot connect to 'http://head.ipa.local/ipa/xml': Internal Server Error
# ls -l /run/user/apache/
# ls: cannot access /run/user/apache: No such file or directory
# cat /etc/tmpfiles.d/httpd.conf
d /var/run/httpd   710 root apache
d /run/user/apache 770 apache apache
# systemd-tmpfiles --create /etc/tmpfiles.d/httpd.conf
# ls -laZ /run/user/apache/
drwxrwx---. apache apache system_u:object_r:httpd_tmp_t:s0 .
drwxr-xr-x. root   root   system_u:object_r:user_tmp_t:s0  ..
# ipa user-find
--------------
1 user matched
--------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 137800000
  GID: 137800000
  Account disabled: False
  Password: True
  Kerberos keys available: True
----------------------------
Number of entries returned 1
----------------------------

One more piece here: we've determined that /run/user/username is inappropriate for a number of reasons. We are switching to /run/user/UID which is much safer (and doesn't require an nsswitch lookup either).

Updating the summary.

After discussing with Simo, we ask to make following changes:

0. Remove mod_auth_kerb update with the /run/user/username change from Fedora 17
1. Keep ownership of /run/user/UID in mod_auth_kerb
2. Add /etc/tmpfiles.d/mod_auth_kerb.conf with
   d /run/user/UID 770 apache apache

Note that this file should be generated upon install and marked as %ghost in the package. The reason for it that we can't really predict uid of apache prior to install.

Of course you could argue this should be in /run/service/UID rather then /run/user, since apache is not a user.

There's also an ongoing discussion as to whether the cred caches should be in /run/auth/UID.

Please hold. I'll update the ticket when that's been hashed out.

The f17 mod_auth_kerb has a crasher bug per comment 10 so we need to do something there.

Apologies for the long delay on a response here.

Paraphrasing from BZ #848226 (similar bug for krb5-appl):

As part of the Fedora 18 features https://fedoraproject.org/wiki/Features/KRB5CacheMove and https://fedoraproject.org/wiki/Features/KRB5DirCache, servers which accept delegated credentials and store them in credential caches for users will need to be taught to put them in a different location.

Specifically, they'll go in /run/user/$UID, and preferably in a "DIR" type ccache rather than the "FILE" type which is currently used.

If that fails for some reason, falling back to the current behavior is going to likely be better than nothing.

FWIW, I don't know that switching from FILE: to DIR:, for this specific case, is going to gain us anything.

Using DIR: is preferable when the processes using the cache which we're setting up (typically a shell session) might want to store an additional initial TGT obtained from a different realm, and to be able to choose which is to use by default.

While it's certainly possible, I don't think it's likely that a process on the server will attempt the equivalent of a 'kinit' to get a brand-new TGT from a different realm, and when we're in the context of a server-side process that's using credentials delegated to it by a client, I'd expect the decision of which client credentials to use to have been implicitly made by the client when it decided which credentials to delegate to the server.

Given that, and the additional work involved in using DIR: ccaches, I believe that mod_auth_kerb is probably going to be better off if it sticks to creating FILE: ccaches.

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

I'm closing this bug. We want to keep ccache type as FILE in mod_auth_kerb, as it is intentional use.