FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2012/9/9 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.
>

At least Linux and HP-UX does not require such things to get access to
command line. Environment perhaps required it but ps returns the
expanded command line

> 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

I vote for getopt too!

However I think that all tools support reading from standard input too
so the patch would only align datacopy to other tools.

Frediano