Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#26 option parsing broken

open
nobody
None
5
2006-01-17
2006-01-17
No

First off, I think this bug came about after this change mentioned in
the ChangeLog:

"2005-09-23 Moriyoshi Koizumi <moriyoshi@users.sourceforge.net>

* pam_mysql.c: (pam_mysql_parse_args): change option parsing
behaviour so "=" following each option name is not needed.

Problem is that if I have a long WHERE clause, it gets chopped off at the
first space encountered.

An example:

where=domain='foo.net' AND status=1

Will be parsed as:

domain='foo.net'

and "AND status=" parsed as a config file error.

In the README, there are examples that show long strings either
quoted or with brackets around them. Brackets don't seem to parse,
and if I quote everything like this:

where="domain='foo.net' AND status=1"

The parser reads the where clause as:

"domain='foo.net'

It includes the first quote literally and still truncates the where clause
at the first space it encounters.

Discussion

  • Logged In: YES
    user_id=995831

    That's nothing to do with the change mentioned above.

    Try encapsulating it with brackets like

    [where=domain='foo.net' AND status=1]

     
  • Logged In: YES
    user_id=35056

    Is this on FreeBSD (or are you using OpenPAM)? I just
    submitted a patch that I had to use to get this to work.

     
  • Logged In: YES
    user_id=829974
    Originator: YES

    It's been awhile... My fix was to just hard-code the query and forget about it.

    I think "mbucc" has the right idea. Brackets are only valid in some PAM implementations, and they don't work for me.

    He has a patch posted here that could be cleaned up and added:

    http://sourceforge.net/tracker/index.php?func=detail&aid=1421525&group_id=5741&atid=305741