Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion bug#12632: file permissions checking mishandled when setuid

Received: by 10.66.83.40 with SMTP id n8mr2735180pay.42.1350956837056;
        Mon, 22 Oct 2012 18:47:17 -0700 (PDT)
Path: 6ni12674pbd.1!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Paul Eggert <egg...@cs.ucla.edu>
Newsgroups: gnu.emacs.bug
Subject: bug#12632: file permissions checking mishandled when setuid
Date: Mon, 22 Oct 2012 18:46:56 -0700
Organization: UCLA Computer Science Department
Lines: 20
Sender: debbugs-submit-boun...@debbugs.gnu.org
Approved: bug-gnu-em...@gnu.org
Message-ID: <mailman.11499.1350956836.855.bug-gnu-emacs@gnu.org>
References: <5078CAB6.7020509@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> <aiipa6uvso.fsf@fencepost.gnu.org>
	<5081ABD6.9060002@cs.ucla.edu> <23r4osd2f9.fsf@fencepost.gnu.org>
	<50836366.6080600@cs.ucla.edu> <odlif0v4e3.fsf@fencepost.gnu.org>
	<5084E1B2.2020105@cs.ucla.edu> <83ipa2ctl2.fsf@gnu.org>
	<5085AD9E.7040701@cs.ucla.edu> <838vaycj65.fsf@gnu.org>
	<5085BB01.2030402@cs.ucla.edu>
	<jwvliey9g4m.fsf-monnier+emacs@gnu.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
X-Trace: usenet.stanford.edu 1350956836 10660 208.118.235.17 (23 Oct 2012 01:47:16 GMT)
X-Complaints-To: action@cs.stanford.edu
Cc: 12...@debbugs.gnu.org
To: Stefan Monnier <monn...@iro.umontreal.ca>
Envelope-to: bug-gnu-em...@gnu.org
X-Loop: help-debb...@gnu.org
Resent-From: Paul Eggert <egg...@cs.ucla.edu>
Original-Sender: debbugs-submit-boun...@debbugs.gnu.org
Resent-CC: bug-gnu-em...@gnu.org
Resent-Date: Tue, 23 Oct 2012 01:49:02 +0000
Resent-Message-ID: <handler.12632.B12632.135095694023...@debbugs.gnu.org>
Resent-Sender: help-debb...@gnu.org
X-GNU-PR-Message: followup 12632
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security patch
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
In-Reply-To: <jwvliey9g4m.fsf-monnier+em...@gnu.org>
X-BeenThere: debbugs-sub...@debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
Errors-To: debbugs-submit-boun...@debbugs.gnu.org
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-em...@gnu.org
List-Id: "Bug reports for GNU Emacs,
	the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-requ...@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-em...@gnu.org>
List-Help: <mailto:bug-gnu-emacs-requ...@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-requ...@gnu.org?subject=subscribe>
X-Received-Bytes: 3885
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10/22/2012 05:40 PM, Stefan Monnier wrote:
>>> We use IS_DIRECTORY_SEP in other places, so why avoid it here?
>> > If it's not needed, it makes the code a bit harder to read.
> I don't see why.  The name says very clearly what it is intended to do.
> On the contrary, it seems more clear than comparing with '/' which only
> makes sense if you happen to know that / is the special char used as
> directory-separator.

Using IS_DIRECTORY_SEP indicates that it's necessary to
process a file name using a system-dependent interpretation
rather than the standard POSIX interpretation.  When
plain X=='/' would do, it can mislead the reader if the code
does IS_DIRECTORY_SEP (X), as the reader may naturally (and
mistakenly) infer that the code was written that way because
it must treat '\' specially on Windows.  It's primarily
this clarity, not the brevity, that I was referring to.