[SSSD] cwrap test roadblock

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Thu Nov 27 22:00:21 UTC 2014


Thank you, Simo.

First of all a disclaimer: I have very little knowledge of libnss_sss
communication with sssd so my judgement is based on a sort of fog.

On 11/27/2014 04:25 PM, Simo Sorce wrote:
> On Thu, 27 Nov 2014 15:09:32 +0200
> Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
>> While trying to arrange running sssd under cwrap in "make check" I
>> came upon this roadblock:
>>
>> There doesn't seem to be a way to make libnsss_sss use server sockets
>> in non-default location at runtime, only at build time. And it seems
>> that doing it at runtime would be a security issue.
>
> Why would it be a security issue ?

I was primarily thinking about environment variables, which I thought would
make it possible to change the libnss_sss responses completely with an
environment variable pointing to a different socket. And environment variables
are sometimes difficult to track and can come from various places.

>> That means that we can't include tests involving libnss_sss into
>> "make check", as that is not guaranteed to be invoked on a build with
>> a special location where the current user can write to.
>
> We can use environment variables to find the socket as long as use
> secure_getenv() (which means they will not work when running as a
> setuid process, but otherwise will).

Wouldn't the non-setuid processes be also endangered by the possibility of
subverting their communication with sssd via environment variables?

If they would, what if we placed some restriction on the socket
ownership/permissions?  Wouldn't it make it simpler? OTOH, I'm not sure how
that would work under cwrap.

> The other option is to have a configuration file that libnsss_sss
> reads, we haven't gone this route so far as we wanted to avoid adding
> file operations to find out sockets, but it wouldn't be very hard to do
> if we keep the file format so simple we do not need a file format
> parser. But then this would again be a system level setting not per
> process, so perhaps the env var route is better for testing anyway.

Um, this replaces the socket path specification problem with config file path
specification problem, essentially.

>> This leaves us with being able to run these tests under CI only,
>> which can arrange for special configure options and thus locations.
>>
>> Could there be another way? Am I missing something?
>
> A last option would be to intercept unix socket calls in socket wrapper
> too, and redirect them.

Hmm, this sounds interesting. But now I'm not sure if sockets is the only way
libnss_sss communicates with sssd (as per my disclaimer above).

Nick



More information about the sssd-devel mailing list