From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:56842 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750877AbdAPVDu (ORCPT ); Mon, 16 Jan 2017 16:03:50 -0500 Message-ID: <1484600605.2540.73.camel@HansenPartnership.com> Subject: Re: [Lsf-pc] Authentication Contexts for network file systems and Containers was Re: [LSF/MM ATTEND] FS jitter testing, network caching, Lustre, cluster filesystems. From: James Bottomley To: Jeffrey Altman Cc: linux-fsdevel , containers@lists.linux-foundation.org, lsf-pc@lists.linux-foundation.org Date: Mon, 16 Jan 2017 13:03:25 -0800 In-Reply-To: References: <20170116171708.GC2953@fieldses.org> <409e0dcb-0e6e-b37a-d8d1-039f92d466ac@auristor.com> <1484588818.2540.43.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 2017-01-16 at 15:39 -0500, Jeffrey Altman wrote: > Error verifying signature: parse error > --------------ms000508080908050405010401 > Content-Type: multipart/mixed; > boundary="------------049F6401F78BABEBFB8F74AC" > > This is a multi-part message in MIME format. > --------------049F6401F78BABEBFB8F74AC > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: quoted-printable > > On 1/16/2017 12:46 PM, James Bottomley wrote: > > > > For identity, doesn't the UTS namespace do this? If not, what is > > missing? > > =20 > > James > > James, > > Thanks for posing the question. > > Unless I'm missing something, the UTS namespace permits an alternate > 'hostname' and NIS 'domainname' to be specified for local visibility > to the processes running in the container. > > For an /afs network file system client (kafs, OpenAFS or AuriStorFS) > the kernel module must be able to associate each process with an > authentication context. The AFS family of file systems have > implemented this binding as part of its Process Authentication Group > (PAG) concept. A PAG is a set of processes that share an > authentication context. The authentication context includes: [...] OK, so snipping all the details: it's a per process property and inherited, I don't even see that it needs anything container specific. The pid namespace should be sufficient to keep any potential security leaks contained and the inheritance model should just work with containers. > While a file system can internally create an association between an > authentication content with a file descriptor once it is created and > with pages for write-back, I believe there would be benefit from a > more generic method of tracking authentication contexts in file > descriptors and pages. In particular would be better defined > behavior when a file has been opened for "write" from processes > associated with more than one authentication context. As long as an "authentication" becomes a property of a file descriptor (like a token), then I don't see any container problems: fds are namespace blind, so they can be passed between containers and your authorizations would go with them. If you need to go back to a process as part of the authorization, then there would be problems because processes are namespaced. > For example, the problems that AFS is currently experiencing with > systemd. A good description of problem by Jonathan Billings can be > found at > > > https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKtI-Qh00c5_9zJa4 > YHjn=pB6ODM/pub This is giving me "Sorry, the file you have requested does not exist." James