FreeTDS Development Group

[Modesto Sevilla <mpsevill AT uci.edu>]

Cedric,
   Thank you for your reply.  We are also in the process of migrating 
from Sybase to MS Sql Server as you are.  We also need an isql tool that 
is identical to Sybase isql but that it will work with MS Sql Server.  
What particular changes have you made to your version of bsqldb?  May be 
if its possible you could share with me your changes so that I could use 
them as well.  We are on Solaris.
Thank you.
> Date: Tue, 18 Aug 2009 14:32:37 -0400
> From: Cedric ROUVRAIS <cedric.rouvrais AT sgcib.com>
>
>
> Hi Modesto,
>
> The issue here that you need to think about is that many people send to
> isql a specified set of commands. Thought will have to be given as to how
> this change will affect behaviour :o)
>
> I can compile for linux server if you wish, the only caveat is that my
> version of bsqldb is different from the current trunk as I have changed to
> make it identical Sybase ISQL as we are migrating from Sybase to SQL
> Server.
>
> a++ Cedric
>
>
>
>
> |------------------------------                                            
> |            Modesto Sevilla                                               
> |            <mpsevill AT uci.edu                                             
> |            >                                                             
> |            Sent by:                                                      
> |            freetds-bounces@l                                             
> |            ists.ibiblio.org                                              
> |                                                                          
> |                                                                          
> |            08/18/2009 01:39                                              
> |            PM                                                            
> |                                                                          
> |                                                                          
> |            Please respond to                                             
> |                 FreeTDS                                                  
> |            Development Group                                             
> |            <freetds AT lists.ib                                             
> |               iblio.org>                                                 
> |                                                                          
> |                                                                          
>                                                                            
>                                                                            
>                                                                         To 
>                                                freetds AT lists.ibiblio.org   
>                                                                         cc 
>                                                                            
>                                                                    Subject 
>                                                [freetds] Hiding password   
>                                                in bsqldb                   
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>
>
>
>
> Hello,
>     I had been searching for a solution to pass in the password to
> bsqldb and freebcp from an encrypted file which would not be displayed
> by using ps while the job is running.  I found that someone was looking
> for the same solution but there was no concrete solution.  While
> studying the code in freebcp.c I saw an undocumented feature that
> actually does the trick.  You can use -P- and it will read the password
> from stdin.
>
>   253                          case 'P':
>   254                                      pdata->Pflag++;
>   255                                      if ((strcmp(optarg, "-")) == 0)
> {
>   256                                                  char pwd[255], *nl;
>   257                                                  memset(pwd, 0, 255);
>   258                                                  fgets(pwd, 255,
> stdin);
>   259                                                  nl = strchr(pwd,
> '\n');
>   260                                                  if(nl) *nl = '\0';
>   261                                                  pdata->pass =
> strdup(pwd);
>   262                                      } else {
>   263                                                  pdata->pass =
> strdup(optarg);
>   264                                      }
>   265                                      break;
>
>
> In my shell script now I am able to do this and the password is not
> displayed in ps.
>
> #!/bin/sh
> getencryptedpw PW | freebcp TABLE out DATFILE -f FMTFILE -S SERVER -U
> USERNAME -P-
>
> The password is resolved and piped into freebcp without displaying
> through ps.
>
> I am not a C programmer so I was wondering if someone could make the
> same change to the other apps such as bsqldb.  I was thinking that it
> would look something like this in bsqldb:
>
>   786                          case 'P':
>   787                                      got_password = 1;
>                                      if ((strcmp(optarg, "-")) == 0) {
>                                                  char pwd[255], *nl;
>                                                  memset(pwd, 0, 255);
>                                                  fgets(pwd, 255, stdin);
>                                                  nl = strchr(pwd, '\n');
>                                                  if(nl) *nl = '\0';
>                                                  DBSETLPWD(login, pwd);
>                                      } else {
>                                                  DBSETLPWD(login, optarg);
>                                      }
>                                      break;
>
> Just wanted to see what people thought and if they find this useful.
> Thank you.
>
> *James K. Lowden* jklowden at freetds.org
> <
> mailto:freetds%40lists.ibiblio.org?Subject=%5Bfreetds%5D%20Hiding%20password%20in%20fisql%20and%20bsqldb&In-Reply-To=BB433306F449CD42BB0F5A06B2B49D0D24A4F8%40dc1mailbox03.mpls.digitalriver.com
>   
> /Mon Dec 22 21:01:59 EST 2008/
>
>     * Previous message: [freetds] Hiding password in fisql and bsqldb
>       <https://lists.ibiblio.org/sympa/arc/freetds/2008q4/024186.html>
>     * Next message: [freetds] Hiding password in fisql and bsqldb
>       <https://lists.ibiblio.org/sympa/arc/freetds/2008q4/024190.html>
>     * *Messages sorted by:* [ date ]
>       <https://lists.ibiblio.org/sympa/arc/freetds/2008q4/date.html#24188>
>       [ thread ]
>       <https://lists.ibiblio.org/sympa/arc/freetds/2008q4/thread.html#24188>
>       [ subject ]
>       <https://lists.ibiblio.org/sympa/arc/freetds/2008q4/subject.html#24188
>   
>       [ author ]
>       <https://lists.ibiblio.org/sympa/arc/freetds/2008q4/author.html#24188>
>
> ------------------------------------------------------------------------
>
> Peter Chase wrote:
>   
> > / I'm trying to use fisql and bsqldb in a bash script and I'm having
> >     
> />/ problems finding a way to hide the password from the ps command without
> />/ requiring user input.
> /
> Yeah, it's a problem.  On my agenda for some time is adding the ability to
> use $HOME/.netrc for that purpose, as some ftp clients do.  sqsh uses
> .sqshrc to do the same thing (except limited to one
> server+username+password tuple).
>
> It would be a welcome patch.
>
> --jkl
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
>
>
> *************************************************************************
> This message and any attachments (the "message") are confidential, intended 
> solely for the addressee(s), and may contain legally privileged information.  
> Any unauthorised use or dissemination is prohibited.  E-mails are susceptible 
> to alteration.  Neither SOCIETE GENERALE nor any of its subsidiaries or 
> affiliates shall be liable for the message if altered, changed or falsified.
> *************************************************************************
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 19 Aug 2009 12:01:04 +0200
> From: Frediano Ziglio <freddy77 AT gmail.com>
> Subject: Re: [freetds] seems dblib can get TDS protocol wrong in
>         unusual case
> To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> Message-ID:
>         <aa1b71110908190301t75d38ee8q99916e31b8d7ba54 AT mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2008/11/12 James K. Lowden <jklowden AT freetds.org>:
>   
> > Hayes, Ted (London) wrote:
> >     
> > > The problem is that dbsqlok() processes the TDS_DONEPROC_RESULT and with
> > > no error flag set in done_flags, sets dbproc->dbresults_state to
> > > _DB_RES_SUCCEED and exits. ?This just makes the subsequent dbresults()
> > > invocation exit immediately, and the results from the second half of the
> > > packet are lost. ?From the TDS specification, it seems to me that maybe
> > > the TDS_DONE_MORE_RESULTS bit in done_flags should cause dbsqlok() to
> > > continue looping to make further tds_process_tokens() invocations.
> > >
> > > I added this at line 4601 of dblib.c
> > >
> > > if (done_flags & TDS_DONE_MORE_RESULTS)
> > > { break; }
> > >
> > > /* else continue with existing code..*/
> > > tdsdump_log(...
> > > dbproc->dbresults_state = _DB_RES_SUCCEED;
> > >
> > > With this change, dbsqlok() carries on and processes additional tokens
> > > including the 0x7c (PROCID) at offset 0x171, the 0xa0 (COLNAME) at 0x17a
> > > and 0xa1 (COLFMT) at 0x188. ?dbsqlok() exits when the 0xae result token
> > > is encountered at 0x191 and dbresults() then successfully processes the
> > > rest of the packet.
> > >       
> > My, what a can of worms you've opened.
> >
> > For the nonce I've improved/broken dbsqlok with this:
> >
> > retcode = (done_flags & TDS_DONE_ERROR)? FAIL : SUCCEED;
> > dbproc->dbresults_state = (done_flags & TDS_DONE_MORE_RESULTS)?
> > ? ? ? ?_DB_RES_NEXT_RESULT : _DB_RES_NO_MORE_RESULTS;
> > return retcode;
> >
> > The code you found in 0.82 is decidedly odd. ?The dbresults_state is set
> > to rows/norows in the fail branch but only to succeed in the succeessful
> > branch.
> >
> > But with the above, even if I include logic to continue gobbling packets
> > (along the lines you suggest), 5 unit tests fail. ?You might try your
> > patch and see. ?Specifically, t0018.c.
> >
> > Now, it might be that the test is bad. ?It looks that way to me. ?But I
> > think I've reached a state of _DB_RES_VERY_CONFUSED, so I'm checking in
> > the broken code and taking a break.
> >
> > Thanks for pointing this out. ?Results processing is, er, important.
> >
> >     
>
> Well... this is the last stopover so I took some time to narrow down...
> After some tests and after checking ms dblib bahavior I think this is
> a false problem. Like ODBC in this case dblib generate a sort of empty
> recordset with no rows. After dbsqlok set dbresults_state to
> _DB_RES_SUCCEED dbresults returns SUCCEED without any token processing
> but it also set dbresults_state to _DB_RES_NEXT_RESULT so on next
> dbresults call token processing take place again without discupting
> anything...
>
> freddy77
>
>
> ------------------------------
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
>
> End of FreeTDS Digest, Vol 79, Issue 18
> ***************************************
>
>
>