Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URI max length hard-coded to 64 characters #21

Closed
tbain98 opened this issue Dec 22, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@tbain98
Copy link

commented Dec 22, 2017

I'm trying to use nslcd in an AWS environment where my LDAP server is behind an Elastic Load Balancer (ELB), and where I'm referencing that load balancer via its (very verbose) A name. The A name I'm using is 74 characters long, and the "ldaps://" at the beginning makes 82 characters, but nslcd/cfg.c uses a hard-coded limit of 64 characters when parsing its tokens from the file (see the token local variable of cfg_read() at line 1268). As a result, nslcd truncates my ELB-based URI to only the first 64 characters and then tries to treat the remainder of the URI as a second URI (which it then complains doesn't start with "ldaps://").

I see two reasonable options:

  • Increase the token size to something much larger, like 256 bytes.
  • Eliminate the problem entirely by changing the parsing code to simply read the line until a delimiter is hit, allowing variable-length tokens (subject to the overall line length limit).

The second option is clearly the better one from a functionality standpoint, but the first would require less development time, which might or might not outweigh the smaller degree of flexibility that comes with it.

NOTE: I'm aware that a workaround to this problem would be to use a DNS service to map a shorter name to the ELB. Unfortunately, that workaround is not an option for me in this case due to restrictions imposed on the project by its requirements, so I'm looking for a solution within nslcd itself rather that a DNS-based workaround.

@tbain98 tbain98 changed the title URI hard-coded to 64-character max URI max length hard-coded to 64 characters Dec 22, 2017

@arthurdejong

This comment has been minimized.

Copy link
Owner

commented Dec 23, 2017

Thanks for pointing this out. I've pushed a fix to set the maximum length to 256 characters. The current code uses fixed length buffers in almost all places in order to have simple memory management (the code it was originally forked from had very difficult to follow memory management).

This change will be in the next release but a date for that release has not yet been set.

In general, depending on your use case, it may be better to configure the LDAP server (or ELB in your case) IP address in nslcd.conf instead of a host name. The main reason for this is that during start-up nslcd can be started before networking is available and negative DNS lookups can be cached by some system components causing lookups to fail for a longer period of time.

nslcd includes a mechanism to clear its own caches and server availability state when the network is (re)connected (usually implemented by sending SIGUSR1 from the network post-up scripts). This allows for some mitigation to the above problem.

Thanks for reporting this.

@tbain98

This comment has been minimized.

Copy link
Author

commented Jan 1, 2018

Thanks for the fix, it's much appreciated.

The problem with the workaround you suggested is that an ELB is associated with potentially more than one IP address at a time (at least one per AZ in which it exists, but there can be more than one per AZ if the load on the ELB requires multiple hosts to support the traffic) and the IPs associated with the ELB can change over time.

The former is the more minor of the problems (at worst, it means that you're not load balancing across the multiple hosts that may be implementing your ELB), but the latter means that as soon as the ELB rolls over IP addresses, your entry is immediately wrong and all connections fail until some process notices and updates that config file. That limitation may be acceptable to some people under some conditions, but for me that's a deal-breaker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.