From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: [PATCH 2/7] Overlayfs: Use copy-up security hooks Date: Mon, 10 Nov 2014 10:45:37 -0500 Message-ID: <3253042.xfZ6VF8OvX@sifl> References: <4109261.WfcAOoSvNG@sifl> <20141105154238.2555.85960.stgit@warthog.procyon.org.uk> <3148.1415397940@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: linux-unionfs@vger.kernel.org, selinux@tycho.nsa.gov, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org To: David Howells Return-path: In-Reply-To: <3148.1415397940@warthog.procyon.org.uk> Sender: linux-unionfs-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Friday, November 07, 2014 10:05:40 PM David Howells wrote: > Paul Moore wrote: > > So the LSM must modify the xattr in place? I suppose that since the > > @value is allocated to the max size it shouldn't be a problem. Just > > checking ... > > ... And the caller must provide a maximally sized buffer (which it likely > has to allocate anyway). > > I'm not sure I really need to provide the modification thing. I suspect a > binary keep or discard decision is sufficient. The docker use case we've been talking about in this thread doesn't really care about the on-disk file labels (xattrs) because the docker folks want to use context= mounts; however if someone did care about on-disk file labels for the upper layer in the overlayfs then they might want to modify the xattr. -- paul moore www.paul-moore.com