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