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(a)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(a)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(a)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(a)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(a)redhat.com>:
>> > > > >
>> > > > >> Rob Verduijn <rob.verduijn(a)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(a)lists.fedorahosted.org
>> > > > To unsubscribe send an email to gss-proxy-leave(a)lists.fedoraho
>>
sted.org
>> > >
>> > >
>> > > --
>> > > Simo Sorce * Red Hat, Inc * New York
>> > > _______________________________________________
>> > > gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>> > > To unsubscribe send an email to gss-proxy-leave(a)lists.fedoraho
>>
sted.org
>> > >
>> > _______________________________________________
>> > gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>> > To unsubscribe send an email to gss-proxy-leave(a)lists.fedorahosted.org
>>
>>
>> --
>> Simo Sorce * Red Hat, Inc * New York
>> _______________________________________________
>> gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>> To unsubscribe send an email to gss-proxy-leave(a)lists.fedorahosted.org
>>
>
>
_______________________________________________
gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
To unsubscribe send an email to gss-proxy-leave(a)lists.fedorahosted.org