Re: [Lsf-pc] Authentication Contexts for network file systems and Containers was Re: [LSF/MM ATTEND] FS jitter testing, network caching, Lustre, cluster filesystems.

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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