Ticket #2629 (closed defect: fixed)

Opened 4 months ago

Last modified 3 months ago

msencrypt'd OGR connections show password on error

Reported by: dmorissette Assigned to: dmorissette
Priority: normal Milestone: 5.0.3 release
Component: OGR Support Version: unspecified
Severity: normal Keywords:
Cc: warmerdam, sdlime

Description

Reported by David Martin on mapserver-users:

I have been doing some work on installing an OGR connection to one of my databases. So decided to use msencrypt to hide the userid and password strings. This works OK however when the OGR breaks for what every reason the system returns a message similar to this:

msDrawMap(): Image handling error. Failed to draw layer named 'Places'. msOGRFileOpen(): OGR error. Open failed for OGR connection `<OGRVRTDataSource> <OGRVRTLayer name='Places'> <SrcDataSource?>ODBC:vsXXXXXXXX_odbc/XXXXXXXXXX@vs285832_1</SrcDataSource> <SrcSQL>SELECT WaypointID, Description, Latitude, Longitude FROM PointPlace?_Waypoints WHERE poi='%poi%'</SrcSQL>

Where the XXX's shown are actually the real user information and passwords for the connection. How can I suppress this error from appearing at all. It seems a little strange to provide an encrypted password and then have the system render the password when the OGR layer fails.

Any help would be great.

David Martin

Change History

05/26/08 08:58:12 changed by dmorissette

  • status changed from new to assigned.

05/26/08 09:30:32 changed by dmorissette

  • cc set to warmerdam, sdlime.

I have committed a fix for this in r7619 (trunk) to avoid displaying any connection string in error messages (encrypted or not). Instead we just refer to the layer by its name in the error messages.

There is still at least one msDebug() statement that could output an unencrypted connection string to the mapserver MS_ERRORFILE in debug mode, but it's there for the purpose of helping admins troubleshoot problems so I left it there.

Finally, there are 4 places where we propagate the error messages from OGR using CPLGetLastErrorMsg(). I don't know what the chances are of those messages containing sensitive information. One possibility would be to send the CPL error info to msDebug() instead of msSetError().

Adding Steve and Frank to CC to get their opinion on this.

05/26/08 09:34:04 changed by dmorissette

I have backported the fix to branch-5-0 in r7620 (future 5.0.3)

06/03/08 10:36:32 changed by dmorissette

  • status changed from assigned to closed.
  • resolution set to fixed.

Closing.