@rgonig2

Maybe I'm missing something...what is the issue with the un-hashed passwords? That they appear in the logs? That's a PHP thing, it logs the function called and everything passed to it.

Here is an excerpt from a dev on PHP's issue tracker:

you shouldn't enable display_errors in production so this shouldn't have any security impact on your site (and secondly, an attacker shouldn't be able to use those credentials to connect to your database from remotely, but that is not in the scope of this question), but hiding the password by default would be a PITA (Pain In The Ass) for those people who are using the error reporting to track down problems like a configuration error, where the connaction fails, because for some reason a wrong password is used.

So in theory this is good as the errors aren't displayed to users, no one should be able to access your server logs, and sometimes the credentials are necessary when debugging.

Cheers.

    KevinTheJedi I may be misunderstanding my institutions issue with it. I'll ask and see what I can figure out.

      @awstech did you ever have any further luck with this? Making some progress at my institution but it's coming slowly.

      KevinTheJedi That quote is from a bug report for PDO which reveals the database connection information in the stack trace, which then gets logged. In that context, there's no harm having the password in the log (as long as the log is only available to the site owner and display_errors is off), since the site owner already knows the correct password for the database connection. In the auth-ldap context, the passwords of all users are being revealed to the website owner. That would be bad even if the accounts were local to osTicket, but when the accounts in question are ldap accounts that are used for access to many other services, it is not safe to allow those passwords to be revealed to the owner of the website. Stack traces are only printed to the log for unhandled exceptions. Resolving the problem should be a simple matter of implementing exception handling.

          Fixed!!!!

          Workaround was to unphar auth-ldap.phar, point the database to the folder, and set isphar=0. Honestly, still not entirely sure what the issue is in the first place...Dunno if the workound hints at that.

          Sounds like phar is disabled on the machine in php.

          @rgonig2

          That quote is from a bug report for PDO which reveals the database connection information in the stack trace, which then gets logged. In that context, there's no harm having the password in the log (as long as the log is only available to the site owner and display_errors is off), since the site owner already knows the correct password for the database connection. In the auth-ldap context, the passwords of all users are being revealed to the website owner. That would be bad even if the accounts were local to osTicket, but when the accounts in question are ldap accounts that are used for access to many other services, it is not safe to allow those passwords to be revealed to the owner of the website. Stack traces are only printed to the log for unhandled exceptions. Resolving the problem should be a simple matter of implementing exception handling.

          Thank you for the suggestion. I will add this to the list of requested features for future versions.

          Cheers.

          On the link that you provided...
          Look at Configure Command section.
          about 60% of the way down you will spot '--disable-phar'

          (Yes I know it says later in the Phar section that it is enabled... but passing that at commandline should disable it)

            ntozier Ah, okay. I did notice that but saw that the plugin enabled later and assumed that meant it ended in an enabled state

              3 years later

              The same problem happened to me, changed the ownership after copying from root to www-data, I am able to configure.
              sudo chown www-data:www-data auth-ldap.phar
              sudo chmod 777 auth-ldap.phar

              2 years later

              Same here I just changed Chown for storage-fs.pfar is the plugin started to work. ¸

              I use MC (Midnight Commander)

              Write a Reply...