From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: set-file-extended-attributes and backups Date: Fri, 21 Dec 2012 18:44:19 +0200 Message-ID: <83a9t7qrrw.fsf@gnu.org> References: <83obhntq1m.fsf@gnu.org> <50D48781.1050303@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1356108283 4949 80.91.229.3 (21 Dec 2012 16:44:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Dec 2012 16:44:43 +0000 (UTC) Cc: romain@orebokech.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 21 17:44:58 2012 Return-path: Envelope-to: ged-emacs-devel@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 1Tm5iQ-0002Zw-MP for ged-emacs-devel@m.gmane.org; Fri, 21 Dec 2012 17:44:54 +0100 Original-Received: from localhost ([::1]:55326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tm5iC-0005GH-V4 for ged-emacs-devel@m.gmane.org; Fri, 21 Dec 2012 11:44:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tm5i8-0005Fj-Ua for emacs-devel@gnu.org; Fri, 21 Dec 2012 11:44:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tm5i6-0000vR-Sv for emacs-devel@gnu.org; Fri, 21 Dec 2012 11:44:36 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:34439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tm5i6-0000vB-KL for emacs-devel@gnu.org; Fri, 21 Dec 2012 11:44:34 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MFE00F003P3Y600@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 21 Dec 2012 18:44:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MFE00FZ53U8NPB0@a-mtaout21.012.net.il>; Fri, 21 Dec 2012 18:44:32 +0200 (IST) In-reply-to: <50D48781.1050303@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155734 Archived-At: > Date: Fri, 21 Dec 2012 08:00:01 -0800 > From: Paul Eggert > Cc: Romain Francoise > > On 12/21/12 06:53, Eli Zaretskii wrote: > > I think this problem is not Windows-specific. So I'm asking here: > > does it make sense to fail backup-buffer and backup-buffer-copy just > > because set-file-extended-attributes fails? I think we should ignore > > such errors > > On systems where ACLs can deny access to files, failing to > copy an ACL can mean that the copy has more permissions > than the original, no? Yes, I think so, at least when we are not backing up by renaming. > Wouldn't that be a security problem? Maybe. But Emacs does the same on platforms where ACLs are not accessible to Emacs, so if there's a security problem, we already have it, I think. > As I understand it, Windows ACLs can deny access, just as > Posix ACLs can, so this issue is relevant on Windows too. Yes, Windows ACLs can deny access, and yes, it is relevant. > The recently-added ACL code has some security holes in > this area, doesn't it? It's copying file mode separately > from copying ACLs. Surely the code should just copy ACLs, > as there's a race condition now, where the file is > temporarily exposed between the times the mode and the > ACLs are copied. How about if it tried to copy ACLs, and if that failed, attempted to copy the file modes? That would DTRT if possible, and fall back on the pre-ACL method if not.