FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Fri, 7 Sep 2012 19:34:51 +0100
Frediano Ziglio <freddy77 AT gmail.com> wrote:

> 
> Il giorno 24/ago/2012, alle ore 19:06, "James K. Lowden"
> <jklowden AT freetds.org> ha scritto:
> 
> > On Thu, 23 Aug 2012 01:16:24 +0000 (UTC)
> > Stuart Henderson <stu AT spacehopper.org> wrote:
> > 
> >>> called "getpass".  Now the command:
> >>> 
> >>>  datacopy -S$S/$U/$(getpass $S)/$D/$T ...
> >>> 
> >>> does the job.
> >> 
> >> This still shows in the command line, though.
> > 
> > No, what shows on the command line is "$(getpass $S)".  
> 
>   James, the shell expand the command so in ps you see the password.
> Perhaps environment is more safe and hard to read but I think pipe or
> external file are better.

Ah, I see.  Thanks for the clarification.  Still, I reject the patch
because, no offense intended, it's the wrong approach.  

Using ps(1) you can seen the expanded result of my
$(getpass $S).  For that to be possible, though, you need to be either 

        1) the user (running under the same effective uid)
or
        2) root

A local file is subject to the same inspection as the process's
environment.  It is thus no better or worse than my solution.  

Granted, it's possible to get the password from another machine
instead using, say, ssh.  Granted also Mr. Slade's patch is less work
than adding Kerberos to datacopy.  IMO it is still too much work for
too little benefit, because very few users will bother to feed standard
input from an off-machine resource.  

I added Kerberos support to the FreeTDS utilities once support for
Kerberos and SSPI were fully integrated into the libraries.  The only
one I didn't touch was datacopy, mosty because I didn't use it.  From
that experience I know it's not hard to do.  

I would be delighted to see a patch bringing Kerberos to datacopy.  For
extra credit, change it to use getopt(3) too.  

--jkl