From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21702: shell-quote-argument semantics and safety Date: Mon, 19 Oct 2015 10:47:28 +0300 Message-ID: <83twpnguzz.fsf@gnu.org> References: <871tcstkuk.fsf@T420.taylan> <83pp0chzax.fsf@gnu.org> <874mhoq9ct.fsf@T420.taylan> <83h9lohsao.fsf@gnu.org> <87h9lnpb0o.fsf@T420.taylan> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1445240962 28310 80.91.229.3 (19 Oct 2015 07:49:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 07:49:22 +0000 (UTC) Cc: 21702@debbugs.gnu.org To: taylanbayirli@gmail.com (Taylan Ulrich =?UTF-8?Q?Bay=C4=B1rl=C4=B1/Kammer?=) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 19 09:49:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zo5Bt-0006cS-QA for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Oct 2015 09:49:09 +0200 Original-Received: from localhost ([::1]:37065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo5Bt-0004kN-55 for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Oct 2015 03:49:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo5Bq-0004kC-JV for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 03:49:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo5Bm-0008Vu-J3 for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 03:49:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo5Bm-0008Vd-GO for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 03:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zo5Bm-0006Ku-3O for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 03:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Oct 2015 07:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21702 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21702-submit@debbugs.gnu.org id=B21702.144524091224320 (code B ref 21702); Mon, 19 Oct 2015 07:49:02 +0000 Original-Received: (at 21702) by debbugs.gnu.org; 19 Oct 2015 07:48:32 +0000 Original-Received: from localhost ([127.0.0.1]:55672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5BH-0006KB-Ks for submit@debbugs.gnu.org; Mon, 19 Oct 2015 03:48:32 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:43771) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5BE-0006K2-Ob for 21702@debbugs.gnu.org; Mon, 19 Oct 2015 03:48:30 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NWG00100IYYSK00@mtaout26.012.net.il> for 21702@debbugs.gnu.org; Mon, 19 Oct 2015 10:50:40 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG00OMIJ4FXD20@mtaout26.012.net.il>; Mon, 19 Oct 2015 10:50:40 +0300 (IDT) In-reply-to: <87h9lnpb0o.fsf@T420.taylan> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107739 Archived-At: > From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer) > Cc: 21702@debbugs.gnu.org > Date: Mon, 19 Oct 2015 09:34:15 +0200 > > > Item 1 was this: > > > >> >> The function should clearly document > >> >> > >> >> 1) for which shells will the quoting work absolutely, i.e. lead to > >> >> the given string to appear *verbatim* in an element of the ARGV of > >> >> the called command, > > > > There's nothing about safety here, only about correctness. That is > > the aspect that I think is now covered, as the doc string now says for > > which shells one can have correct results. > > Usually it's indeed correctness that protects against injection attacks. > A quoting mechanism that's correct is automatically safe. And that is the current situation, AFAIU. > Another way to make it safe would be to error when the given string > contains characters outside of a limited character set. What limited set would you suggest that will not make the function useless in real-life scenarios? In any case, I think quoting is better than rejecting, as it supports more use cases. > Either way, the safeness should be documented clearly, either implicitly > through a clear documentation of the correctness, or explicitly. Like I said, this convention should be adopted project-wide. Doing so only in a few doc strings, let alone one, will only confuse, because the user will not know whether the lack of such documentation means the API is safe or unsafe. > I would propose something along the lines of: > > It is guaranteed that ARGUMENT will be parsed as a single token by > shells X, Y, and Z, as long as it is separated from other text via a > delimiter in the syntax of the respective shell. I don't think we want to mention specific shells explicitly, because maintaining such a list would be a burden. The standard shell of each OS is well defined and known to the users of the respective systems. Moreover, Emacs by default uses that shell automatically. > >> Does that make sense? > > > > Maybe it does, but only if we start documenting these aspects > > project-wide. It makes little sense to me to do that for a single > > API, and not an important one at that. But that's me. > > This is an API which if its implementation is imperfect will result in > programs prone to code injection attacks when these programs face > untrusted input sources. Why do you say it's not an important one? Because there are many much more important ones that can do much more harm more easily. In particular, a shell command doesn't need to be quoted to be harmful or malicious.