From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 16:44:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D2D9106566C for ; Mon, 12 Jan 2009 16:44:52 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id F1CFF8FC1D for ; Mon, 12 Jan 2009 16:44:51 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0CGipC1012970; Mon, 12 Jan 2009 08:44:51 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <496B7380.10804@freebsd.org> Date: Mon, 12 Jan 2009 08:44:48 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> <496AA714.1090904@freebsd.org> <496ABD9A.8080006@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, pluknet Subject: Re: extattr problems? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 16:44:52 -0000 Robert Watson wrote: > On Sun, 11 Jan 2009, Tim Kientzle wrote: > >> I think this one is a bug. It appears that extattr_set_fd() obeys the >> permissions on the file, not the permissions of the descriptor. > > Hmm. Not clear. EAs live in a slightly hazy world between data and > meta-data. Normally you can perform operations like fchmod(2), which > are strictly meta-data operations, regardless of the flags of the file > descriptor they are performed on, subject to ownership/permissions. You can always call fchmod() on a newly-created file. But you cannot currently always call extattr_set_fd() on a newly created file. So extattr_set_fd() does not currently behave like other metadata operations. > With NFSv4 ACLs, where the right to change ACLs can be delegated, this > only becomes more true. I've chosen to generally treat EAs as meta-data > in this regard, where the file descriptor simply names the object rather > than as an access method as occurs with write(), etc. Hmmmm.... Then what is the secure way to create a file with no write permissions and EAs? The policy you've adopted means that you must open write permissions on the file even if the final file should not have such permissions. I'm also unclear about your reasoning here. There are only two ways to get a writable FD: You have write permissions on an existing file (or rather, *had* write permissions at the time you opened it), or you've just created the file. The former case would seem to cover your concerns here; I see no justification for disallowing the latter. I'm especially unhappy about this in the case of tar because it means I would have to introduce another system call (an otherwise-redundant fchmod()) into the performance-critical file creation path, not to mention some rather ugly logic to modify modes on newly created files if that file has extattrs and you're on FreeBSD. > How do other > systems handle this -- for example, Linux, with its notion of user vs. > system namespaces? I need to do some more research here. I'll let you know what I find. Tim