all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Michael Mauger via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Andrew Hyatt <ahyatt@gmail.com>
Cc: "8427\\@debbugs.gnu.org" <8427@debbugs.gnu.org>,
	Stefan Kangas <stefan@marxist.se>
Subject: bug#8427: [SECURITY] sql.el -- comint process passwords are leaked to ps(1) listing
Date: Sat, 02 Nov 2019 19:41:44 +0000	[thread overview]
Message-ID: <u_uGj_CkU2ybAJY2RScZiP6A42Au7oS1S8o3gms-jy5rTPWsSs58VR5pdeI3wt7ZWTNYWfAuJXSPBxYrBxRpl3Ea0wGEr11E0k298vBJqyA=@protonmail.com> (raw)
In-Reply-To: <menftj7ytex.fsf@ahyatt-macbookpro6.roam.corp.google.com>

On Saturday, November 2, 2019 1:10 AM, Andrew Hyatt <ahyatt@gmail.com> wrote:

> Michael Mauger mmauger@protonmail.com writes:
>
> > On Sunday, October 20, 2019 8:56 PM, Andrew Hyatt ahyatt@gmail.com wrote:
> >
>
> Your advice is good, but following it led me to some complexity I can't
> seem to get away from. Perhaps you have some insight, so let me explain.
> The issue is that, yes, I can not advise the comint function. However,
> if I supply my own function, then I have to remove the
> comint-watch-for-password-prompt, supply my own function, then restore
> it when the user has entered their password (so it can handle subsequent
> password entries). This juggling of the normal
> comint-watch-for-password-prompt method, plus the fact that we basically
> have to reimplement part of it, gives me pause - I think it's probably
> too hacky a solution.
>
> There's a few ways out. We could introduce a variable used in
> sql-product-alist that tells SQL not to prompt for a password because
> the db will just get it via the comint password function. That would
> probably work well, but it wouldn't store the sql-password at all, that
> variable would be unused. Maybe that's OK, maybe not - I don't have a
> good sense for it.
>
> Or, we could make this auto-password-supplying per-buffer a part of
> comint itself. That would widen the scope of the fix, but it would
> probably be the best of both functionality and simplicity.
>
> What do you think?
>

I totally understand the complexity, but I don't think it has too be too
complicated to address.

First the sql.el only solution: If the sql-comint function decides to pass
the password via stdin then it can set a buffer-local flag indicating this
and then replace `coming-watch-for-password-prompt' on the
`comint-output-filter-functions' list with the sql version of the function.
The sql password function would be something along the lines of:

    ;; TOTALLY NOT TESTED
    (defun sql-watch-for-password-prompt (string)
      "blah blah ;)"
      (if sql-will-prompt-for-password
          ;; (based on comint-watch-for-password-prompt)  vvv
          (when (let ((case-fold-search t))
                  (string-match (or (sql-get-product-feature sql-product 'password-prompt-regexp string)
                                    comint-password-prompt-regexp)))
            (when (string-match "^[ \n\r\t\v\f\b\a]+" string)
              (setq string (replace-match "" t t string)))
            (let ((comint--prompt-recursion-depth (1+ comint--prompt-recursion-depth)))
              (if (> comint--prompt-recursion-depth 10)
                  (message "Password prompt recursion too deep")
                ;;; ^^^
                ;;; automagically provide the password
                (let ((proc (get-buffer-process (current-buffer))))
                  (when proc
                    (funcall comint-input-sender proc sql-password))))))
        ;; Back to default behavior
        (comint-watch-for-password-prompt string))
      ;; Make sure we don't supply again
      (setq-local sql-will-prompt-password nil))

That should get you close without too much difficulty. Of course, it requires a
that a password-prompt-regexp feature is defined for the sql product and that the
sql-comint function defines a buffer-local flag `sql-will-prompt-for-password' in
it is deferring to stdin.

The other solution would involve modifying comint to call a hook if set to supply
a password or nil. This would probably be a simpler change but may get more
broader attention. When the hook function is not set or returns nil then do the
default behavior of calling `comint-send-invisible' otherwise just send the password

There are some edge cases here, but this hopefully helps. Also, obviously, test cases
are needed given that if this breaks, we break the sql interactive world!

--
MICHAEL@MAUGER.COM // FSF and EFF member // GNU Emacs sql.el maintainer







  reply	other threads:[~2019-11-02 19:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 11:27 bug#8427: [SECURITY] sql.el -- comint process passwords are leaked to ps(1) listing Jari Aalto
2012-02-28 23:35 ` bug#8427: (no subject) Michael Mauger
2014-03-06  2:06 ` bug#8427: [SECURITY] sql.el -- comint process passwords are leaked to ps(1) listing Glenn Morris
2014-03-07 23:02   ` Stefan Monnier
2018-01-07 17:54     ` Andrew Hyatt
2019-10-06  3:28 ` Stefan Kangas
2019-10-13  1:51   ` Andrew Hyatt
2019-10-13 22:09     ` Stefan Kangas
     [not found]       ` <meny2xh8p4o.fsf@ahyatt-macbookpro6.roam.corp.google.com>
2019-10-20 15:57         ` bug#8427: Fwd: " Stefan Kangas
2019-10-20 16:02           ` Stefan Kangas
2019-10-21  0:56             ` Andrew Hyatt
2019-10-21 20:33               ` Michael Mauger via Bug reports for GNU Emacs, the Swiss army knife of text editors
2019-11-02  1:10                 ` Andrew Hyatt
2019-11-02 19:41                   ` Michael Mauger via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2019-11-11  5:31                     ` Andrew Hyatt
2019-12-16  4:59                       ` Andrew Hyatt
2019-12-16 15:12                         ` Michael Mauger via Bug reports for GNU Emacs, the Swiss army knife of text editors
2019-12-18  6:15                           ` Andrew Hyatt
2019-12-18 12:45                             ` Michael Mauger via Bug reports for GNU Emacs, the Swiss army knife of text editors
2019-12-18 16:57                               ` Eli Zaretskii
2019-12-18 17:52                                 ` Michael Mauger via Bug reports for GNU Emacs, the Swiss army knife of text editors
2019-12-30 15:11                                   ` Andrew Hyatt
2019-12-30 18:34                                     ` Michael Albinus
2019-12-30 19:26                                       ` Andrew Hyatt
2019-12-30 19:39                                         ` Eli Zaretskii
2019-12-30 23:36                                           ` Michael Mauger via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 12:45                                             ` Lars Ingebrigtsen
2021-10-12  5:05                                               ` Stefan Kangas
2021-10-13 16:05                                                 ` Michael Mauger via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-13 17:47                                                   ` Stefan Kangas
2021-10-13 18:26                                                     ` Eli Zaretskii
2021-10-13 21:26                                                       ` Stefan Kangas
2021-10-19  4:37                                                         ` Michael Mauger via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-19 11:58                                                           ` Eli Zaretskii
2021-10-19 12:05                                                             ` Michael Albinus
2021-11-05  7:11                                                           ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='u_uGj_CkU2ybAJY2RScZiP6A42Au7oS1S8o3gms-jy5rTPWsSs58VR5pdeI3wt7ZWTNYWfAuJXSPBxYrBxRpl3Ea0wGEr11E0k298vBJqyA=@protonmail.com' \
    --to=bug-gnu-emacs@gnu.org \
    --cc=8427@debbugs.gnu.org \
    --cc=ahyatt@gmail.com \
    --cc=mmauger@protonmail.com \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.