From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#12632: file permissions checking mishandled when setuid Date: Mon, 22 Oct 2012 22:07:16 -0700 Organization: UCLA Computer Science Department Message-ID: <50862604.30208@cs.ucla.edu> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1350968898 25687 80.91.229.3 (23 Oct 2012 05:08:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2012 05:08:18 +0000 (UTC) Cc: 12632@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 23 07:08:24 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 1TQWj2-0007Tw-Dp for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Oct 2012 07:08:24 +0200 Original-Received: from localhost ([::1]:55658 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQWiu-0006l7-Gt for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Oct 2012 01:08:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQWir-0006kp-MF for bug-gnu-emacs@gnu.org; Tue, 23 Oct 2012 01:08:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQWiq-000885-IF for bug-gnu-emacs@gnu.org; Tue, 23 Oct 2012 01:08:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQWiq-000880-En for bug-gnu-emacs@gnu.org; Tue, 23 Oct 2012 01:08:12 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TQWkc-0004uU-F7 for bug-gnu-emacs@gnu.org; Tue, 23 Oct 2012 01:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Oct 2012 05:10: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.135096895518810 (code B ref 12632); Tue, 23 Oct 2012 05:10:02 +0000 Original-Received: (at 12632) by debbugs.gnu.org; 23 Oct 2012 05:09:15 +0000 Original-Received: from localhost ([127.0.0.1]:56683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TQWjr-0004tL-BC for submit@debbugs.gnu.org; Tue, 23 Oct 2012 01:09:15 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:36651) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TQWjn-0004t7-Kb for 12632@debbugs.gnu.org; Tue, 23 Oct 2012 01:09:13 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D2740A6000A; Mon, 22 Oct 2012 22:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msA2H4MuCqsP; Mon, 22 Oct 2012 22:07:15 -0700 (PDT) Original-Received: from [192.168.1.3] (pool-108-23-119-2.lsanca.fios.verizon.net [108.23.119.2]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 5AD8EA60009; Mon, 22 Oct 2012 22:07:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 In-Reply-To: <836261df2p.fsf@gnu.org> 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:65902 Archived-At: On 10/22/2012 08:47 PM, Eli Zaretskii wrote: >> > Is it possible in Windows that the searchability of the file named "//" >> > differs from the searchability of "/"? Or that the searchability >> > of "\/" differs from that of "\"? > Both is true. // or \\ or \/ starts a UNC, and Windows expects the > following to be the name of a remote machine. / or \ is just the root > directory of the current drive. Sorry, apparently I wasn't clear. I wasn't asking about names like //remotemachine or /directory, as names like that should not be affected by this issue. I was asking about bare // and bare / and their aliases with backslash. Let me try to be more concrete. 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) >> Can you give an example of how that might affect the test? > > 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?