On Tue, 2017-01-17 at 11:29 -0500, Jeffrey Altman wrote: > Error verifying signature: parse error > On 1/16/2017 4:03 PM, James Bottomley wrote: > > [...] > > > > 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. > > Agreed. > > > > 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_9 > > > zJa4 > > > YHjn=pB6ODM/pub > > > > This is giving me "Sorry, the file you have requested does not > > exist." > > Not sure how an extra '=' got in there. > > https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKtI-Qh00c5_9zJa4 > YHjnpB6ODM/pub > > Jeffrey Altman > There is the usual problem when you have to do an upcall in order to set up the authentication context for session based protocols, such as RPCSEC_GSS. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
