go-ldap / ldif Goto Github PK

As it stands, the library unconditionally loads the contents from the file system when using the URL directive (:<), both in standard attributes and in control values. However, this makes the parser unusable for loading untrusted input without first sanitizing it. As the LDIF RFC spec notes, care should be taken when parsing untrusted input, as the file URL functionality allows malicious actors to read files from the local system (such as /etc/hostname or /etc/passwd).

While it's possible to disable the parsing of Controls entirely with the Controls boolean flag in the LDIF struct (which has the effect of disabling loading files inside control values), it's not possible to disable this behavior for attribute values. It would be preferrable to have some additional option when calling ldif.Unmarshal that allows for turning off the parser's behavior of following and loading file URLs when using the :< directive.

When we use modify, nothing appens https://github.com/go-ldap/ldif/blob/master/ldif.go#L235

Currently the ToLDIF function checks for types from ldapV2. Is it possible to rewrite the module import using go.mod?

Is a linebreak considered an empty value?

		b, err := os.ReadFile(*f)
		if err != nil {
			fmt.Println(err)
		}
		res, err = pkg.ParseUsers(string(b))

where ParseUsers(b) is a function which utilizes ldif.Parse, for an ldif file with several entries I get "Error in line 29: empty value" even when I cut it down to the first two chunks of entries and the file has no line 29 (sorry for the words used, I merely write code which deals with data I get handed and don't have much experience with ldap).

My assumption from the ldif dump I got, and the tests I've seen in your code, is that ldif entries are separated by linebreaks. Why does this happen?

URI = file:///c:/WINDOWS/clock.avi
Path = /c:/WINDOWS/clock.avi

We have a error when we execute this line https://github.com/go-ldap/ldif/blob/master/ldif.go#L455

Given output from ldapsearch -L ... the first line as being version: 1.

From ldapsearch(1) manual page:

-L: Search results are display in LDAP Data Interchange Format detailed in ldif(5). A single -L restricts the output to LDIFv1.
A second -L disables comments. A third -L disables printing of the LDIF version. The default is to use an extended version of LDIF.

I used -L because without it you get an 'extended version' which includes a line result: 0 success (and one other), which results in a parse failure.

With -L you still get a version: 1 line. This does parse successfully, but leaves the first Entry in Entries as nil, which subsequently causes the AllEntries() method to crash because it tries to dereference a nil pointer.

As a workaround, I either have to use -LLL, or use -L and remove the first line, which is version: 1.

I am using github.com/go-ldap/ldif v0.0.0-20200320164324-fd88d9b715b3

Thank you for creating this library, it is very useful for me at the moment as I get back to some Go.

given an LDIF dump with an entry containing this attribute:
dircount: some.server.domain.tld 1 76 846
I get:
Error in line 84: illegal base64 data at input byte 15

The python implementation for ldif dumps does not complain about this.

value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
                                ":" FILL (BASE64-STRING) /
                                "<" FILL url)
                           ; See notes 7 and 8, below

SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
                           ; any value <= 127 decimal except NUL, LF,
                           ; and CR

SAFE-INIT-CHAR           = %x01-09 / %x0B-0C / %x0E-1F /
                           %x21-39 / %x3B / %x3D-7F
                           ; any value <= 127 except NUL, LF, CR,
                           ; SPACE, colon (":", ASCII 58 decimal)
                           ; and less-than ("<" , ASCII 60 decimal)

SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]

This include SPACE (32) if I'm right, so is the error right? The specs say that spaces are allowed.

It would be good to see potential performance improvements merged, like #18