Hello,

I recreated the reproducer environment and tried it with only the keytab relocation
so I added the following steps:
mkdir /var/kerberos/krb5/user/48/
cp /var/lib/gssproxy/clients/httpd.keytab /var/kerberos/krb5/user/48/client.keytab
chcon -t krb5_keytab_t /var/kerberos/krb5/user/48/client.keytab
chown apache:apache /var/kerberos/krb5/user/48/client.keytab
systemctl restart gssproxy.service


and the nfs mount is readable by the apache user
su - apache -s /bin/bash
ls /test
example.txt

[root@fedoraclient ~]# getenforce
Enforcing

so I guess we are incorrectly blaming selinux for this,
but it should be :
https://pagure.io/gssproxy/issue/178

Rob Verduijn


2017-04-03 21:12 GMT+02:00 Rob Verduijn <rob.verduijn@gmail.com>:
Hi just tested it with the keytab copied to
/var/kerberos/krb5/user/48/client.keytab

ls -alsZ /var/kerberos/krb5/user/48/
total 12
4 drwxr-xr-x. 2 root   root   unconfined_u:object_r:var_t:s0         4096 Apr  3 19:05 .
4 drwxr-xr-x. 3 root   root   system_u:object_r:var_t:s0             4096 Apr  3 19:04 ..
4 -rw-------. 1 apache apache unconfined_u:object_r:krb5_keytab_t:s0  558 Apr  3 19:04 client.keytab

and it works in permissive mode
yay,,,,,
one more bug to take care off.......
when it rains it pours......


Rob


2017-04-03 15:18 GMT+02:00 Simo Sorce <simo@redhat.com>:
On Sun, 2017-04-02 at 12:01 +0200, Rob Verduijn wrote:
> Hello,
>
> I did set the selinux config to disabled in /etc/selinix/config
> After this the share was still unavailable to the apache user.
> However I saw in the logs there was now a huge amount of logging when
> trying to access the share as the apache user.
> See the attachment.
>
> I used the vagrant reproducer environment for this.

It seem this is due to: https://pagure.io/gssproxy/issue/178
and not the originall issue you had.
If you remove the HTTP own section-file, does it work for you ?

Simo.

> Rob
>
> 2017-04-01 0:21 GMT+02:00 Simo Sorce <simo@redhat.com>:
>
> > On Fri, 2017-03-31 at 23:24 +0200, Rob Verduijn wrote:
> > > I noticed it also failes when I completely disable selinux (not just
> > > permissive mode)
> > >
> > > What indicates that this is a similar selinux issue ?
> >
> > Testing showed that manually starting the rcp.gssd program instead of
> > letting it be started by the init system did not cause the misbehavior
> > we were seeing.
> >
> > When you say "disable" do you mean really disabling selinux at boot or
> > do you mean setting it in permissive mode ?
> >
> > if you manually start the rpc.gsssd program as the root use after you
> > export the GSS_USE_PROXY variable in the shell does the behavior
> > change ?
> >
> > Simo.
> >
> > > Rob
> > >
> > > 2017-03-31 23:18 GMT+02:00 Rob Verduijn <rob.verduijn@gmail.com>:
> > >
> > > > Hi,
> > > >
> > > > You were right, it does not show up in the logs.
> > > >
> > > > And sadly adding the policy below does not work either :-(
> > > > #cat my-gssproxy.te
> > > > module my-gssproxy 2.0;
> > > >
> > > > require {
> > > >         type init_t;
> > > >         type gssd_t;
> > > >         class process noatsecure;
> > > > }
> > > >
> > > > #============= init_t ==============
> > > > allow init_t gssd_t:process noatsecure;
> > > >
> > > > Then applied it :
> > > > checkmodule -M -m -o my-gssproxy.mod my-gssproxy.te
> > > > semodule_package -o my-gssproxy.pp -m my-gssproxy.mod
> > > > semodule -i my-gssproxy.pp
> > > >
> > > > It needs more work
> > > > I think I'll dig a bit further into this and see if I can come up with
> > > > something.
> > > >
> > > > Rob
> > > >
> > > >
> > > >
> > > > 2017-03-31 21:12 GMT+02:00 Simo Sorce <simo@redhat.com>:
> > > >
> > > >> On Fri, 2017-03-31 at 20:39 +0200, Rob Verduijn wrote:
> > > >> > In that case a workaround should not be so difficult :-)
> > > >> >
> > > >> > lets fire up ausearch
> > > >>
> > > >> I do not know if it shouws up in the audit log becauxe this is a
> > > >> decision made by libc based on the AT_SECURE flag that is set in the
> > > >> process based on selinux policies.
> > > >> So technically there isn't a violation happening.
> > > >>
> > > >> In bz#1174915 there is a similar issue and the solution there was to
> > add
> > > >> this to the policy:
> > > >> allow NetworkManager_t openvpn_t:process { noatsecure };
> > > >>
> > > >> I am not sure what would be the policy in rpc.gssd case, perhaps
> > > >> something like: allow init_t gssd_t:process { noatsecure }; ?
> > > >>
> > > >> Simo.
> > > >>
> > > >> > Rob.
> > > >> >
> > > >> > 2017-03-31 19:02 GMT+02:00 Simo Sorce <simo@redhat.com>:
> > > >> >
> > > >> > > Good news Rob,
> > > >> > > apparently it ended up being a SELinux policy issue,
> > > >> > > see: https://bugzilla.redhat.com/show_bug.cgi?id=1430963
> > > >> > >
> > > >> > > Simo.
> > > >> > >
> > > >> > > On Tue, 2017-03-28 at 17:44 +0200, Rob Verduijn wrote:
> > > >> > > > I guess this has low priority for the nfs devs.
> > > >> > > >
> > > >> > > > Any workaround for this that does not require creating a service
> > > >> account
> > > >> > > in
> > > >> > > > ipa ?
> > > >> > > >
> > > >> > > > Rob Verduijn
> > > >> > > >
> > > >> > > >
> > > >> > > > 2017-03-10 12:37 GMT+01:00 Rob Verduijn <rob.verduijn@gmail.com
> > >:
> > > >> > > >
> > > >> > > > > Cool...this thing was driving me nuts
> > > >> > > > >
> > > >> > > > > Looking forward to the patch.
> > > >> > > > >
> > > >> > > > > Rob
> > > >> > > > >
> > > >> > > > > 2017-03-10 2:14 GMT+01:00 Robbie Harwood <rharwood@redhat.com
> > >:
> > > >> > > > >
> > > >> > > > >> Rob Verduijn <rob.verduijn@gmail.com> writes:
> > > >> > > > >>
> > > >> > > > >> > I've tried quite a lot of things (including the very latest
> > > >> version
> > > >> > > > >> 0.7.0
> > > >> > > > >> > of gssproxy) but I keep failing to get it to work on
> > fedora25.
> > > >> > > > >> >
> > > >> > > > >> > So in a last ditch attempt I created a reproducer in the
> > form
> > > >> of a
> > > >> > > > >> vagrant
> > > >> > > > >> > script that creates a test environment that has the
> > problem.
> > > >> > > > >>
> > > >> > > > >> Hi Rob,
> > > >> > > > >>
> > > >> > > > >> Thanks for the (maximally) detailed reproducer.  I was able
> > to
> > > >> observe
> > > >> > > > >> the issue on my end.  I observed that GSS_USE_PROXY=yes is
> > > >> indeed set
> > > >> > > in
> > > >> > > > >> rpc.gssd's environment.  gssproxy isn't logging anything
> > because
> > > >> it
> > > >> > > > >> never gets invoked.  rpc.gssd has broken the environment
> > variable
> > > >> > > which
> > > >> > > > >> we check using secure_getenv().
> > > >> > > > >>
> > > >> > > > >> I've opened https://bugzilla.redhat.com/
> > show_bug.cgi?id=1430963
> > > >> for
> > > >> > > this
> > > >> > > > >> issue.
> > > >> > > > >>
> > > >> > > > >> --Robbie
> > > >> > > > >>
> > > >> > > > >
> > > >> > > > >
> > > >> > > > _______________________________________________
> > > >> > > > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > > >> > > > To unsubscribe send an email to gss-proxy-leave@lists.fedoraho
> > > >> sted.org
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Simo Sorce * Red Hat, Inc * New York
> > > >> > > _______________________________________________
> > > >> > > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > > >> > > To unsubscribe send an email to gss-proxy-leave@lists.fedoraho
> > > >> sted.org
> > > >> > >
> > > >> > _______________________________________________
> > > >> > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > > >> > To unsubscribe send an email to gss-proxy-leave@lists.
> > fedorahosted.org
> > > >>
> > > >>
> > > >> --
> > > >> Simo Sorce * Red Hat, Inc * New York
> > > >> _______________________________________________
> > > >> gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > > >> To unsubscribe send an email to gss-proxy-leave@lists.
> > fedorahosted.org
> > > >>
> > > >
> > > >
> > > _______________________________________________
> > > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org
> >
> >
> > --
> > Simo Sorce * Red Hat, Inc * New York
> > _______________________________________________
> > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org
> >
> _______________________________________________
> gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org


--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org