From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Race-condition ? Date: Fri, 24 Jun 2005 23:01:50 +0200 Message-ID: <85ll4zwjsx.fsf@lola.goethe.zz> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1119734467 30112 80.91.229.2 (25 Jun 2005 21:21:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 25 Jun 2005 21:21:07 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 25 23:21:07 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DmI5C-0004y1-Aw for ged-emacs-devel@m.gmane.org; Sat, 25 Jun 2005 23:20:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DmIAw-0005CO-Fs for ged-emacs-devel@m.gmane.org; Sat, 25 Jun 2005 17:26:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DmIAL-00057j-3l for emacs-devel@gnu.org; Sat, 25 Jun 2005 17:26:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DmIAG-00055H-Fh for emacs-devel@gnu.org; Sat, 25 Jun 2005 17:26:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DmIAG-00054t-3S for emacs-devel@gnu.org; Sat, 25 Jun 2005 17:26:12 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DmIBo-0004Z4-UQ for emacs-devel@gnu.org; Sat, 25 Jun 2005 17:27:48 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DmI6k-0008VZ-OD; Sat, 25 Jun 2005 17:22:37 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 8D6F81C452C6; Fri, 24 Jun 2005 23:01:51 +0200 (CEST) Original-To: Eli Zaretskii In-Reply-To: (Eli Zaretskii's message of "Fri, 24 Jun 2005 22:07:35 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:39516 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39516 Eli Zaretskii writes: >> From: gaetan.leurent@ens.fr (=?iso-8859-1?Q?Ga=EBtan?= LEURENT) >> Date: Fri, 24 Jun 2005 17:07:57 +0200 >> >> > * fileio.c (Frename_file): Preserve owner and group, if possible, >> > when copying. >> >> This is done with a call to chown, and I think this is a source of >> race-conditions, like the one that was recently discovered in bzip2 >> (someone could have replaced the file by a link to another file between >> Fcopy_file and chown). > > So? What problems would that cause, except defeating the call to > chown itself? Previous versions of Emacs didn't call chown at all, so > how is the current version worse? > > It's possible that this race condition is harmful in the context of > bzip2, but that doesn't necessarily mean it's as harmful in Emacs. > >> I believe we should use fchown instead. > > Only if the danger is real, IMHO: fchown requires that we open the > file, which is expensive. If we go that way, we might as well check > if we are root, and only open the file and call fchown if we are: no > need to punish mere mortals if we know in advance the call will fail > for them anyway. > >> In fileio.c there is also a call to chmod in copy-file which seem to >> suffer the same problem. This one is also in emacs 21.4. > > Yeah, and many versions before that. > > Anyway, how portable are fchown and fchmod? If not all platforms > support them, we shouldn't introduce them without an Autoconf test. I fail to see the advantage of using chown, or using fopen and fchown. In both cases the file name can be changed to refer to something else before the operation starts. The only situation where fchown offers any advantage is where you _already_ have a file open, like when you write the file after fopen, and then change its permissions. That is, the owner change must be accomplished in something like write-region, or it is pointless. As an isolated operation, fopen/fchown offers no advantage whatsoever. You could conceivable to fopen, followed by fstat, check that you are not talking about a symbolic link, and only then to fchown, and this would be safe against symlink attacks. But apart from that, I see no specific advantage. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum