Ticket #47384 (plugin library path validation) and out-of-tree modules

[Nalin Dahyabhai]

Hi, everyone.

I was recently adding a couple of changes to slapi-nis, and when I went
to run its self-tests, some of the tests that modify the plugin entry
started failing with LDAP_UNWILLING_TO_PERFORM.  I tracked the denial
down to validation code that was added as part of ticket #47384.

While the tests don't modify the nsslapd-pluginPath attribute (the
entry's added to dse.ldif before the server starts up), some make other
changes to the plugin entry, and when they attempt that,
check_plugin_path() rejects the modify request.

The checks that were added, which ensure that plugins are only loaded
from the server's plugin directory, make it kind of difficult to run
tests using the copies of plugins in my build tree.

The language in the ticket description's pretty firm that this isn't
going to be changed, and while I can _probably_ work around it on my
end, I figured I'd ask here before going down that route:  is there room
to expand this check to a whitelist, a search path, or some other method
that could be used to provide for my use case?

Thanks,

Nalin

[Rich Megginson]

On 11/19/2013 09:44 AM, Nalin Dahyabhai wrote:
> Hi, everyone.
>
> I was recently adding a couple of changes to slapi-nis, and when I went
> to run its self-tests, some of the tests that modify the plugin entry
> started failing with LDAP_UNWILLING_TO_PERFORM.  I tracked the denial
> down to validation code that was added as part of ticket #47384.
>
> While the tests don't modify the nsslapd-pluginPath attribute (the
> entry's added to dse.ldif before the server starts up), some make other
> changes to the plugin entry, and when they attempt that,
> check_plugin_path() rejects the modify request.
>
> The checks that were added, which ensure that plugins are only loaded
> from the server's plugin directory, make it kind of difficult to run
> tests using the copies of plugins in my build tree.
>
> The language in the ticket description's pretty firm that this isn't
> going to be changed, and while I can _probably_ work around it on my
> end, I figured I'd ask here before going down that route:  is there room
> to expand this check to a whitelist, a search path, or some other method
> that could be used to provide for my use case?

Sure.  Please file a ticket.  We can figure out some way to hack this 
for testing.  What would you suggest?
> Thanks,
> Nalin
>
> 389-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-devel

[Nalin Dahyabhai]

On Tue, Nov 19, 2013 at 10:05:13AM -0700, Rich Megginson wrote:
> On 11/19/2013 09:44 AM, Nalin Dahyabhai wrote:
> > The language in the ticket description's pretty firm that this isn't
> > going to be changed, and while I can _probably_ work around it on my
> > end, I figured I'd ask here before going down that route:  is there room
> > to expand this check to a whitelist, a search path, or some other method
> > that could be used to provide for my use case?
>
> Sure.  Please file a ticket.  We can figure out some way to hack
> this for testing.  What would you suggest?

Great!  I've opened ticket #47601 for this, and we can continue there if
you like.  In case there's more to discuss on the list, here are the
options that come to mind:
* When checking a modify request, only check the nsslapd-pluginPath
  value if it shows up in the mods list.
* Add a run-time-configurable whitelist of acceptable locations.
* Replace the check with logic to go ahead and try loading the module,
  unloading it if the load succeeds.

I haven't tried any of these, but I think any of them would be enough.

Thanks,

Nalin

[Rich Megginson]

On 11/19/2013 11:06 AM, Nalin Dahyabhai wrote:
> On Tue, Nov 19, 2013 at 10:05:13AM -0700, Rich Megginson wrote:
> > On 11/19/2013 09:44 AM, Nalin Dahyabhai wrote:
> > > The language in the ticket description's pretty firm that this isn't
> > > going to be changed, and while I can _probably_ work around it on my
> > > end, I figured I'd ask here before going down that route:  is there room
> > > to expand this check to a whitelist, a search path, or some other method
> > > that could be used to provide for my use case?
> >
> > Sure.  Please file a ticket.  We can figure out some way to hack
> > this for testing.  What would you suggest?
>
> Great!  I've opened ticket #47601 for this, and we can continue there if
> you like.

Yes.
> In case there's more to discuss on the list, here are the
> options that come to mind:
> When checking a modify request, only check the nsslapd-pluginPath
>  value if it shows up in the mods list.
> Add a run-time-configurable whitelist of acceptable locations.
> Replace the check with logic to go ahead and try loading the module,
>  unloading it if the load succeeds.
>
> I haven't tried any of these, but I think any of them would be enough.
>
> Thanks,
>
> Nalin