Skip to Content.
Sympa Menu

freetds - Re: [freetds] Hiding password in bsqldb [NC] (Cedric ROUVRAIS) [NC]

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Cedric ROUVRAIS <cedric.rouvrais AT sgcib.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Hiding password in bsqldb [NC] (Cedric ROUVRAIS) [NC]
  • Date: Thu, 20 Aug 2009 18:44:44 -0400

Hi Modesto,

As soon as we have finished going through our apps and making sure we have
full compatibility I will send you the code source. i will send it to the
group too.

If you wish I can send as I have fixed the latest issue reported by one of
my teams.

a++ Cedric



|------------------------------
| Modesto Sevilla
| <mpsevill AT uci.edu
| >
| Sent by:
| freetds-bounces@l
| ists.ibiblio.org
|
|
| 08/20/2009 02:27
| PM
|
|
| Please respond to
| FreeTDS
| Development Group
| <freetds AT lists.ib
| iblio.org>
|
|


To
freetds AT lists.ibiblio.org
cc

Subject
Re: [freetds] Hiding
password in bsqldb [NC]
(Cedric ROUVRAIS)











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
> ***************************************
>
>
>
_______________________________________________
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.
*************************************************************************





Archive powered by MHonArc 2.6.24.

Top of Page