I noticed it also failes when I completely disable selinux (not just permissive mode)
What indicates that this is a similar selinux issue ?
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