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#12632: file permissions checking mishandled when setuid Date: Tue, 23 Oct 2012 18:44:57 +0200 Message-ID: <83vce1b0ja.fsf@gnu.org> References: <5078CAB6.7020509@cs.ucla.edu> <83fw5h5yo6.fsf@gnu.org> <507B010F.20105@cs.ucla.edu> <831uh06gqd.fsf@gnu.org> <507B15B0.2040802@cs.ucla.edu> <83txtw4xmk.fsf@gnu.org> <507B2354.3030408@cs.ucla.edu> <83sj9g4vy7.fsf@gnu.org> <507BAA6C.2000601@cs.ucla.edu> <83lif74p78.fsf@gnu.org> <507C823D.40304@cs.ucla.edu> <83d30j3wqg.fsf@gnu.org> <507CF802.6000305@cs.ucla.edu> <83a9vm4bmv.fsf@gnu.org> <50818763.80501@cs.ucla.edu> <83wqymz4me.fsf@gnu.org> <5081A1DF.9000009@cs.ucla.edu> <5081ABD6.9060002@cs.ucla.edu> <23r4osd2f9.fsf@fencepost.gnu.org> <50836366.6080600@cs.ucla.edu> <5084E1B2.2020105@cs.ucla.edu> <83ipa2ctl2.fsf@gnu.org> <5085AD9E.7040701@cs.ucla.edu> <838vaycj65.fsf@gnu.org> <5085BB01.2030402@cs.ucla.edu> <836261df2p.fsf@gnu.org> <50862604.30208@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1351010780 4530 80.91.229.3 (23 Oct 2012 16:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2012 16:46:20 +0000 (UTC) Cc: 12632@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 23 18:46:28 2012 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 1TQhcY-00043M-Px for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Oct 2012 18:46:27 +0200 Original-Received: from localhost ([::1]:45549 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQhcR-0003bQ-92 for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Oct 2012 12:46:19 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQhcN-0003bK-Px for bug-gnu-emacs@gnu.org; Tue, 23 Oct 2012 12:46:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQhcH-00088R-Uy for bug-gnu-emacs@gnu.org; Tue, 23 Oct 2012 12:46:15 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQhcH-00088K-RG for bug-gnu-emacs@gnu.org; Tue, 23 Oct 2012 12:46:09 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TQhe6-0004r9-9U for bug-gnu-emacs@gnu.org; Tue, 23 Oct 2012 12:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Oct 2012 16:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12632 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security patch Original-Received: via spool by 12632-submit@debbugs.gnu.org id=B12632.135101084518618 (code B ref 12632); Tue, 23 Oct 2012 16:48:02 +0000 Original-Received: (at 12632) by debbugs.gnu.org; 23 Oct 2012 16:47:25 +0000 Original-Received: from localhost ([127.0.0.1]:58045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TQhdU-0004qF-B4 for submit@debbugs.gnu.org; Tue, 23 Oct 2012 12:47:24 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:36912) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TQhdR-0004q1-Da for 12632@debbugs.gnu.org; Tue, 23 Oct 2012 12:47:22 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MCC00A00U78S200@a-mtaout20.012.net.il> for 12632@debbugs.gnu.org; Tue, 23 Oct 2012 18:44:58 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MCC00ACFUIYMG40@a-mtaout20.012.net.il>; Tue, 23 Oct 2012 18:44:58 +0200 (IST) In-reply-to: <50862604.30208@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.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:65931 Archived-At: > Date: Mon, 22 Oct 2012 22:07:16 -0700 > From: Paul Eggert > CC: rgm@gnu.org, 12632@debbugs.gnu.org > > Which of the following calls can fail on Windows in the current > Emacs trunk, and why? > > sys_access ("/", D_OK) sys_access ("/.", D_OK) > sys_access ("\\", D_OK) sys_access ("\\.", D_OK) > sys_access ("//", D_OK) sys_access ("//.", D_OK) > sys_access ("/\\", D_OK) sys_access ("/\\.", D_OK) > sys_access ("\\/", D_OK) sys_access ("\\/.", D_OK) > sys_access ("\\\\", D_OK) sys_access ("\\\\.", D_OK) > sys_access ("///", D_OK) sys_access ("///.", D_OK) Sorry, I cannot afford doing this research. Some of these file names have no meaning at all, so they are prone to undefined behavior. Others, like "//.", are downright dangerous, because "\\.\" begins a device name on Windows. With these arcana notoriously under-documented by MS, it is anybody's guess what such names can do in what APIs. I'm trying to avoid potential problems before they have a chance to screw some user. I don't see a reason to seek a 110% provable test case, when the issue at hand is a single use of a macro that is used all over the place in Emacs. There isn't a single comparison with a literal '/' in fileio.c, with the sole exception of supporting the "/:" magic. More than 50 instances of IS_DIRECTORY_SEP, just in that one file (and several dozens more elsewhere in Emacs), are the evidence that IS_DIRECTORY_SEP _is_ the norm, whereas a literal slash is an exception. Contrary to your original claim, using '/' will confuse the reader into thinking that this particular function does something special, like the code which looks for the "/:" magic, while using IS_DIRECTORY_SEP will look like any other code we have, and will also DTRT instead of relying on "maybe it will work". > > The call to faccessat could fail, just because of the "\/." at the > > end of the file name. > > Sorry, I don't follow this example. The code doesn't append > backslash-slash-dot; it appends slash-dot. Are you saying that > in the current trunk, sys_access ("\\", D_OK) can succeed > but sys_access ("\\/.", D_OK) can fail when presented with > the same file system? No, I'm saying that if the function is called with "d:\foo\", it will call faccessat with "d:\foo\/." as the argument, which has "\/." at the end of the file name. Testing with IS_DIRECTORY_SEP will avoid this and call faccessat with "d:\foo/.". The latter is a valid file name, while the former is not.