Re: Proposed patch to datacopy to allow passwords to be read from stdin
Frediano Ziglio <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <CAHt6W4dnKnZJpByZNDfiOc39qr7JEOtXzogwQ4+RtPJfHD9kNQ@mail.gmail.com> |
2012/9/9 James K. Lowden <[email protected]>: > On Fri, 7 Sep 2012 19:34:51 +0100 > Frediano Ziglio <[email protected]> wrote: > >> >> Il giorno 24/ago/2012, alle ore 19:06, "James K. Lowden" >> <[email protected]> ha scritto: >> >> > On Thu, 23 Aug 2012 01:16:24 +0000 (UTC) >> > Stuart Henderson <[email protected]> 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