[GRASS-dev] [GRASS GIS] #1951: Postgres database login problems in db.databases

[GRASS GIS]

#1951: Postgres database login problems in db.databases
---------------------------------------------------+------------------------
 Reporter:  davidinosauro                          |       Owner:  grass-dev@…              
     Type:  defect                                 |      Status:  new                      
 Priority:  normal                                 |   Milestone:  7.0.0                    
Component:  Database                               |     Version:  svn-trunk                
 Keywords:  python, postgres, login, db.databases  |    Platform:  Linux                    
      Cpu:  x86-64                                 |  
---------------------------------------------------+------------------------

Comment(by glynn):

 Replying to [comment:5 neteler]:
 > In order to get interactive password prompting back (removed in r32551),
 > could we use code from here for *only* db.login?

 Maybe. At a minimum, interactive prompting would need to be specifically
 requested. If db.login is spawned from the GUI, trying to interact with
 the user via stdin or /dev/tty isn't likely to be useful.

 While the GUI can (and should) just close/redirect stdin prior to
 executing commands, intercepting an explicit open("/dev/tty") is somewhat
 harder (I'm not sure that the equivalent is even possible on Windows).

 It might be better to have db.login spawn an external program for such
 things, with the program specified by an environment variable and/or
 command-line option. This would keep all of the platform-specific ugliness
 out of db.login itself, and would also allow the use of different programs
 in different environments (e.g. a dialog box for GUI environments).

 Assuming that the password is being stored somewhere (presumably this is
 required so that subsequent db.* or v.* commands can connect
 automatically), it's essential that reasonable security precautions are
 taken.

 An external program could either transmit the password back to db.login,
 or could persist as an agent (similar to ssh-agent) which would be
 accessed by subsequent modules. In the latter case, the password need only
 be stored in the agent's memory; however, this would necessitate the use
 of sockets or similar IPC mechanisms.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1951#comment:6>
GRASS GIS <http://grass.osgeo.org>