From: Trond Myklebust <trondmy@hammerspace.com>
To: "sfrench@samba.org" <sfrench@samba.org>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>
Cc: "rgb@redhat.com" <rgb@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH 02/27] containers: Implement containers as kernel objects
Date: Sun, 17 Feb 2019 18:57:54 +0000 [thread overview]
Message-ID: <8c95213ae0981bd7af928902fcb34d6a9dedaa6f.camel@hammerspace.com> (raw)
In-Reply-To: <155024685321.21651.1504201877881622756.stgit@warthog.procyon.org.uk>
SGkgRGF2aWQsDQoNCk9uIEZyaSwgMjAxOS0wMi0xNSBhdCAxNjowNyArMDAwMCwgRGF2aWQgSG93
ZWxscyB3cm90ZToNCj4gSW1wbGVtZW50IGEga2VybmVsIGNvbnRhaW5lciBvYmplY3Qgc3VjaCB0
aGF0IGl0IGNvbnRhaW5zIHRoZQ0KPiBmb2xsb3dpbmcNCj4gdGhpbmdzOg0KPiANCj4gICgxKSBO
YW1lc3BhY2VzLg0KPiANCj4gICgyKSBBIHJvb3QgZGlyZWN0b3J5Lg0KPiANCj4gICgzKSBBIHNl
dCBvZiBwcm9jZXNzZXMsIGluY2x1ZGluZyBvbmUgZGVzaWduYXRlZCBhcyB0aGUgJ2luaXQnDQo+
IHByb2Nlc3MuDQo+IA0KPiBBIGNvbnRhaW5lciBpcyBjcmVhdGVkIGFuZCBhdHRhY2hlZCB0byBh
IGZpbGUgZGVzY3JpcHRvciBieToNCj4gDQo+IAlpbnQgY2ZkID0gY29udGFpbmVyX2NyZWF0ZShj
b25zdCBjaGFyICpuYW1lLCB1bnNpZ25lZCBpbnQNCj4gZmxhZ3MpOw0KPiANCj4gdGhpcyBpbmhl
cml0cyBhbGwgdGhlIG5hbWVzcGFjZXMgb2YgdGhlIHBhcmVudCBjb250YWluZXIgdW5sZXNzDQo+
IG90aGVyd2lzZQ0KPiB0aGUgbWFzayBjYWxscyBmb3IgbmV3IG5hbWVzcGFjZXMuDQo+IA0KPiAJ
Q09OVEFJTkVSX05FV19GU19OUw0KPiAJQ09OVEFJTkVSX05FV19FTVBUWV9GU19OUw0KPiAJQ09O
VEFJTkVSX05FV19DR1JPVVBfTlMgW3Jvb3Qgb25seV0NCj4gCUNPTlRBSU5FUl9ORVdfVVRTX05T
DQo+IAlDT05UQUlORVJfTkVXX0lQQ19OUw0KPiAJQ09OVEFJTkVSX05FV19VU0VSX05TDQo+IAlD
T05UQUlORVJfTkVXX1BJRF9OUw0KPiAJQ09OVEFJTkVSX05FV19ORVRfTlMNCj4gDQo+IE90aGVy
IGZsYWdzIGluY2x1ZGU6DQo+IA0KPiAJQ09OVEFJTkVSX0tJTExfT05fQ0xPU0UNCj4gCUNPTlRB
SU5FUl9DTE9TRV9PTl9FWEVDDQo+IA0KPiBOb3RlIHRoYXQgSSd2ZSBhZGRlZCBhIHBvaW50ZXIg
dG8gdGhlIGN1cnJlbnQgY29udGFpbmVyIHRvDQo+IHRhc2tfc3RydWN0Lg0KPiBUaGlzIGRvZXNu
J3QgbWFrZSB0aGUgbnNwcm94eSBwb2ludGVyIHJlZHVuZGFudCBhcyB5b3UgY2FuIHN0aWxsIG1h
a2UNCj4gbmV3DQo+IG5hbWVzcGFjZXMgd2l0aCBjbG9uZSgpLg0KPiANCj4gSSd2ZSBhbHNvIGFk
ZGVkIGEgbGlzdF9oZWFkIHRvIHRhc2tfc3RydWN0IHRvIGZvcm0gYSBsaXN0IGluIHRoZQ0KPiBj
b250YWluZXINCj4gb2YgaXRzIG1lbWJlciBwcm9jZXNzZXMuICBUaGlzIGlzIGNvbnZlbmllbnQs
IGJ1dCByZWR1bmRhbnQgc2luY2UgdGhlDQo+IGNvZGUNCj4gY291bGQgaXRlcmF0ZSBvdmVyIGFs
bCB0aGUgdGFza3MgbG9va2luZyBmb3Igb25lcyB0aGF0IGhhdmUgYQ0KPiBtYXRjaGluZw0KPiB0
YXNrLT5jb250YWluZXIuDQo+IA0KPiBJdCBtaWdodCBtYWtlIHNlbnNlIHRvIHVzZSBmc2NvbmZp
ZygpIHRvIGNvbmZpZ3VyZSB0aGUgY29udGFpbmVyOg0KPiANCj4gCWZzY29uZmlnKGNmZCwgRlND
T05GSUdfU0VUX05BTUVTUEFDRSwgInVzZXIiLCBOVUxMLCB1c2VybnNfZmQpOw0KPiAJZnNjb25m
aWcoY2ZkLCBGU0NPTkZJR19TRVRfTkFNRVNQQUNFLCAibW50IiwgTlVMTCwgbW50bnNfZmQpOw0K
PiAJZnNjb25maWcoY2ZkLCBGU0NPTkZJR19TRVRfRkQsICJyb290ZnMiLCBOVUxMLCByb290X2Zk
KTsNCj4gCWZzY29uZmlnKGNmZCwgRlNDT05GSUdfQ01EX0NSRUFURV9DT05UQUlORVIsIE5VTEws
IE5VTEwsIDApOw0KPiANCj4gDQo+ID09PT09PT09PT09PT09PT09PQ0KPiBGVVRVUkUgREVWRUxP
UE1FTlQNCj4gPT09PT09PT09PT09PT09PT09DQo+IA0KPiAgKDEpIFNldHRpbmcgdXAgdGhlIGNv
bnRhaW5lci4NCj4gDQo+ICAgICAgQSBjb250YWluZXIgd291bGQgYmUgY3JlYXRlZCB3aXRoLCBz
YXk6DQo+IA0KPiAJaW50IGNmZCA9IGNvbnRhaW5lcl9jcmVhdGUoImZyZWQiLCBDT05UQUlORVJf
TkVXX0VNUFRZX0ZTX05TKTsNCj4gDQo+ICAgICAgT25jZSBjcmVhdGVkLCBpdCBzaG91bGQgdGhl
biBiZSBwb3NzaWJsZSBmb3IgdGhlIHN1cGVydmlzaW5nDQo+IHByb2Nlc3MNCj4gICAgICB0byBt
b2RpZnkgdGhlIG5ldyBjb250YWluZXIuICBNb3VudHMgY2FuIGJlIGNyZWF0ZWQgaW5zaWRlIG9m
DQo+IHRoZQ0KPiAgICAgIGNvbnRhaW5lcidzIG5hbWVzcGFjZXM6DQo+IA0KPiAJZnNmZCA9IGZz
b3BlbigiZXh0NCIsIDApOw0KPiAJZnNjb25maWcoZnNmZCwgRlNDT05GSUdfU0VUX0NPTlRBSU5F
UiwgTlVMTCwgTlVMTCwgY2ZkKTsNCj4gCWZzY29uZmlnKGZzZmQsIEZTQ09ORklHX1NFVF9TVFJJ
TkcsICJzb3VyY2UiLCAiL2Rldi9zZGEzIiwgMCk7DQo+IAlmc2NvbmZpZyhmc2ZkLCBGU0NPTkZJ
R19TRVRfRkxBRywgInVzZXJfeGF0dHIiLCBOVUxMLCAwKTsNCj4gCWZzY29uZmlnKGZzZmQsIEZT
Q09ORklHX0NNRF9DUkVBVEUsIE5VTEwsIE5VTEwsIDApOw0KPiAJbWZkID0gZnNtb3VudChmc2Zk
LCAwLCAwKTsNCj4gDQo+ICAgICAgYW5kIHRoZW4gbW91bnRlZCBpbnRvIHRoZSBuYW1lc3BhY2U6
DQo+IA0KPiAJbW92ZV9tb3VudChtZmQsICIiLCBjZmQsICIvIiwNCj4gCQkgICBNT1ZFX01PVU5U
X0ZfRU1QVFlfUEFUSCB8DQo+IE1PVkVfTU9VTlRfVF9DT05UQUlORVJfUk9PVCk7DQo+IA0KPiAg
ICAgIEZ1cnRoZXIgbW91bnRzIGNhbiBiZSBhZGRlZCBieToNCj4gDQo+IAltb3ZlX21vdW50KG1m
ZCwgIiIsIGNmZCwgInByb2MiLCBNT1ZFX01PVU5UX0ZfRU1QVFlfUEFUSCk7DQo+IA0KPiAgICAg
IEZpbGVzIGFuZCBkZXZpY2VzIGNhbiBiZSBjcmVhdGVkIGJ5IHN1cHBseWluZyB0aGUgY29udGFp
bmVyIGZkDQo+IGFzIHRoZQ0KPiAgICAgIGRpcmZkIGFyZ3VtZW50Og0KPiANCj4gCW1rZGlyYXQo
aW50IGNmZCwgY29uc3QgY2hhciAqcGF0aCwgbW9kZV90IG1vZGUpOw0KPiAJbWtub2RhdChpbnQg
Y2ZkLCBjb25zdCBjaGFyICpwYXRoLCBtb2RlX3QgbW9kZSwgZGV2X3QgZGV2KTsNCj4gCWludCBm
ZCA9IG9wZW5hdChpbnQgY2ZkLCBjb25zdCBjaGFyICpwYXRoLA0KPiAJCQl1bnNpZ25lZCBpbnQg
ZmxhZ3MsIG1vZGVfdCBtb2RlKTsNCj4gDQo+ICAgICAgWypdIE5vdGUgdGhhdCB3aGVuIHVzaW5n
IGNmZCBhcyBkaXJmZCwgdGhlIHBhdGggbXVzdCBub3QgY29udGFpbg0KPiBhICcvJw0KPiAgICAg
IAkgYXQgdGhlIGZyb250Lg0KPiANCj4gICAgICBTb2NrZXRzLCBzdWNoIGFzIG5ldGxpbmssIGNh
biBiZSBvcGVuZWQgaW5zaWRlIG9mIHRoZQ0KPiBjb250YWluZXIncw0KPiAgICAgIG5hbWVzcGFj
ZXM6DQo+IA0KPiAJaW50IGZkID0gY29udGFpbmVyX3NvY2tldChpbnQgY2ZkLCBpbnQgZG9tYWlu
LCBpbnQgdHlwZSwNCj4gCQkJCSAgaW50IHByb3RvY29sKTsNCj4gDQo+ICAgICAgVGhpcyBzaG91
bGQgYWxsb3cgbWFuYWdlbWVudCBvZiB0aGUgY29udGFpbmVyJ3MgbmV0d29yaw0KPiBuYW1lc3Bh
Y2UgZnJvbQ0KPiAgICAgIG91dHNpZGUuDQo+IA0KPiAgKDIpIFN0YXJ0aW5nIHRoZSBjb250YWlu
ZXIuDQo+IA0KPiAgICAgIE9uY2UgYWxsIG1vZGlmaWNhdGlvbnMgYXJlIGNvbXBsZXRlLCB0aGUg
Y29udGFpbmVyJ3MgJ2luaXQnDQo+IHByb2Nlc3MNCj4gICAgICBjYW4gYmUgc3RhcnRlZCBieToN
Cj4gDQo+IAlmb3JrX2ludG9fY29udGFpbmVyKGludCBjZmQpOw0KPiANCj4gICAgICBUaGlzIHBy
ZWNsdWRlcyBmdXJ0aGVyIGV4dGVybmFsIG1vZGlmaWNhdGlvbiBvZiB0aGUgbW91bnQgdHJlZQ0K
PiB3aXRoaW4NCj4gICAgICB0aGUgY29udGFpbmVyLiAgQmVmb3JlIHRoaXMgcG9pbnQsIHRoZSBj
b250YWluZXIgaXMgc2ltcGx5DQo+IGRlc3Ryb3llZA0KPiAgICAgIGlmIHRoZSBjb250YWluZXIg
ZmQgaXMgY2xvc2VkLg0KPiANCj4gICgzKSBXYWl0aW5nIGZvciB0aGUgY29udGFpbmVyIHRvIGNv
bXBsZXRlLg0KPiANCj4gICAgICBUaGUgY29udGFpbmVyIGZkIGNhbiB0aGVuIGJlIHBvbGxlZCB0
byB3YWl0IGZvciBpbml0IHByb2Nlc3MNCj4gdGhlcmVpbg0KPiAgICAgIHRvIGNvbXBsZXRlIGFu
ZCB0aGUgZXhpdCBjb2RlIGNvbGxlY3RlZCBieToNCj4gDQo+IAljb250YWluZXJfd2FpdChpbnQg
Y29udGFpbmVyX2ZkLCBpbnQgKl93c3RhdHVzLCB1bnNpZ25lZCBpbnQNCj4gd2FpdCwNCj4gCQkg
ICAgICAgc3RydWN0IHJ1c2FnZSAqcnVzYWdlKTsNCj4gDQo+ICAgICAgVGhlIGNvbnRhaW5lciBh
bmQgZXZlcnl0aGluZyBpbiBpdCBjYW4gYmUgdGVybWluYXRlZCBvciBraWxsZWQNCj4gb2ZmOg0K
PiANCj4gCWNvbnRhaW5lcl9raWxsKGludCBjb250YWluZXJfZmQsIGludCBpbml0b25seSwgaW50
IHNpZ25hbCk7DQo+IA0KPiAgICAgIElmICdpbml0JyBkaWVzLCBhbGwgb3RoZXIgcHJvY2Vzc2Vz
IGluIHRoZSBjb250YWluZXIgYXJlDQo+IHByZWVtcHRpdmVseQ0KPiAgICAgIFNJR0tJTEwnZCBi
eSB0aGUga2VybmVsLg0KPiANCj4gICAgICBCeSBkZWZhdWx0LCBpZiB0aGUgY29udGFpbmVyIGlz
IGFjdGl2ZSBhbmQgaXRzIGZkIGlzIGNsb3NlZCwgdGhlDQo+ICAgICAgY29udGFpbmVyIGlzIGxl
ZnQgcnVubmluZyBhbmQgd2lsIGJlIGNsZWFuZWQgdXAgd2hlbiBpdHMgJ2luaXQnDQo+IGV4aXRz
Lg0KPiAgICAgIFRoZSBkZWZhdWx0IGNhbiBiZSBjaGFuZ2VkIHdpdGggdGhlIENPTlRBSU5FUl9L
SUxMX09OX0NMT1NFDQo+IGZsYWcuDQo+IA0KPiAgKDQpIFN1cGVydmlzaW5nIHRoZSBjb250YWlu
ZXIuDQo+IA0KPiAgICAgIEdpdmVuIHRoYXQgd2UgaGF2ZSBhbiBmZCBhdHRhY2hlZCB0byB0aGUg
Y29udGFpbmVyLCB3ZSBjb3VsZA0KPiBtYWtlIGl0DQo+ICAgICAgc3VjaCB0aGF0IHRoZSBzdXBl
cnZpc2luZyBwcm9jZXNzIGNvdWxkIG1vbml0b3IgYW5kIG92ZXJyaWRlDQo+IEVQRVJNDQo+ICAg
ICAgcmV0dXJucyBmb3IgbW91bnQgYW5kIG90aGVyIHByaXZpbGVnZWQgb3BlcmF0aW9ucyB3aXRo
aW4gdGhlDQo+ICAgICAgY29udGFpbmVyLg0KPiANCj4gICg1KSBQZXItY29udGFpbmVyIGtleXJp
bmcuDQo+IA0KPiAgICAgIEVhY2ggY29udGFpbmVyIGNhbiBwb2ludCB0byBhIHBlci1jb250YWlu
ZXIga2V5cmluZyBmb3IgdGhlDQo+IGhvbGRpbmcgb2YNCj4gICAgICBpbnRlZ3JpdHkga2V5cyBh
bmQgZmlsZXN5c3RlbSBrZXlzIGZvciB1c2UgaW5zaWRlIHRoZQ0KPiBjb250YWluZXIuICBUaGlz
DQo+ICAgICAgd291bGQgYmUgYXR0YWNoZWQ6DQo+IA0KPiAJa2V5Y3RsKEtFWUNUTF9TRVRfQ09O
VEFJTkVSX0tFWVJJTkcsIGNmZCwga2V5cmluZykNCj4gDQo+ICAgICAgVGhpcyBrZXlyaW5nIHdv
dWxkIGJlIHNlYXJjaGVkIGJ5IHJlcXVlc3Rfa2V5KCkgYWZ0ZXIgaXQgaGFzDQo+IHNlYXJjaGVk
DQo+ICAgICAgdGhlIHRocmVhZCwgcHJvY2VzcyBhbmQgc2Vzc2lvbiBrZXlyaW5ncy4NCj4gDQo+
ICAoNikgUnVubmluZyBkaWZmZXJlbnQgTFNNIHBvbGljaWVzIGJ5IGNvbnRhaW5lci4gIFRoaXMg
bWlnaHQNCj4gcGFydGljdWxhcmx5DQo+ICAgICAgbWFrZSBzZW5zZSB3aXRoIHNvbWV0aGluZyBs
aWtlIEFwcGFybW9yIHdoZXJlIGRpZmZlcmVudCBwYXRoLQ0KPiBiYXNlZA0KPiAgICAgIHJ1bGVz
IG1pZ2h0IGJlIHJlcXVpcmVkIGluc2lkZSBhIGNvbnRhaW5lciB0byBpbnNpZGUgdGhlIHBhcmVu
dC4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IERhdmlkIEhvd2VsbHMgPGRob3dlbGxzQHJlZGhhdC5j
b20+DQo+IC0tLQ0KDQpEbyB3ZSByZWFsbHkgbmVlZCBhIG5ldyBzeXN0ZW0gY2FsbCB0byBzZXQg
dXAgY29udGFpbmVycz8gVGhhdCB3b3VsZA0KZm9yY2UgY2hhbmdlcyB0byBhbGwgZXhpc3Rpbmcg
b3JjaGVzdHJhdGlvbiBzb2Z0d2FyZS4NCg0KR2l2ZW4gdGhhdCB0aGUgbWFpbiB0aGluZyB3ZSB3
YW50IHRvIGFjaGlldmUgaXMgdG8gZGlyZWN0IG1lc3NhZ2VzIGZyb20NCnRoZSBrZXJuZWwgdG8g
YW4gYXBwcm9wcmlhdGUgaGFuZGxlciwgd2h5IG5vdCBmb2N1cyBvbiBhZGRpbmcNCmZ1bmN0aW9u
YWxpdHkgdG8gZG8ganVzdCB0aGF0Pw0KDQpJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSBhIHN5c2Nh
bGwgdG8gYWxsb3cgYW4gYXBwcm9wcmlhdGVseSBwcml2aWxlZ2VkDQpwcm9jZXNzIHRvIGFkZCBh
IGtleXJpbmctc3BlY2lmaWMgbWVzc2FnZSBxdWV1ZSB0byBpdHMgb3duDQp1c2VyX25hbWVzcGFj
ZSBhbmQgb2J0YWluIGEgZmlsZSBkZXNjcmlwdG9yIHRvIHRoYXQgbWVzc2FnZSBxdWV1ZSBtaWdo
dA0Kbm90IHdvcms/IFRoYXQgZm9yY2VzIHRoZSBjb250YWluZXIgdG8gdXNlIGEgZGFlbW9uIGlm
IGl0IGNhcmVzIHRvDQppbnRlcmNlcHQga2V5cmluZyB0cmFmZmljLCByYXRoZXIgdGhhbiB3b3Jy
eWluZyBhYm91dCB0aGUga2VybmVsDQpydW5uaW5nIHJlcXVlc3Rfa2V5IChpbiBmYWN0LCBpdCBt
aWdodCBtYWtlIHNlbnNlIHRvIGFsbG93IGEgdHJpdmlhbA0KaW1wbGVtZW50YXRpb24gb2YgdGhl
IGRhZW1vbiB0byBiZSB0byBqdXN0IHJlYWQgdGhlIG1lc3NhZ2VzLCBwYXJzZQ0KdGhlbSBhbmQg
cnVuIHJlcXVlc3Rfa2V5KS4NCg0KV2l0aCBzdWNoIGFuIGltcGxlbWVudGF0aW9uLCB0aGUgZmFs
bGJhY2sgbWVjaGFuaXNtIGNvdWxkIGJlIHRvIHdhbGsNCmJhY2sgdXAgdGhlIGhpZXJhcmNoeSBv
ZiB1c2VyX25hbWVzcGFjZXMgdW50aWwgYSBtZXNzYWdlIHF1ZXVlIGlzDQpmb3VuZCwgYW5kIHRv
IGludm9rZSB0aGUgZXhpc3RpbmcgcmVxdWVzdF9rZXkgbWVjaGFuaXNtIGlmIG5vdC4NCg0KLS0g
DQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lciwgSGFtbWVyc3Bh
Y2UNCnRyb25kLm15a2xlYnVzdEBoYW1tZXJzcGFjZS5jb20NCg0KDQo
WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trondmy@hammerspace.com>
To: "sfrench@samba.org" <sfrench@samba.org>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>
Cc: "rgb@redhat.com" <rgb@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH 02/27] containers: Implement containers as kernel objects
Date: Sun, 17 Feb 2019 18:57:54 +0000 [thread overview]
Message-ID: <8c95213ae0981bd7af928902fcb34d6a9dedaa6f.camel@hammerspace.com> (raw)
In-Reply-To: <155024685321.21651.1504201877881622756.stgit@warthog.procyon.org.uk>
Hi David,
On Fri, 2019-02-15 at 16:07 +0000, David Howells wrote:
> Implement a kernel container object such that it contains the
> following
> things:
>
> (1) Namespaces.
>
> (2) A root directory.
>
> (3) A set of processes, including one designated as the 'init'
> process.
>
> A container is created and attached to a file descriptor by:
>
> int cfd = container_create(const char *name, unsigned int
> flags);
>
> this inherits all the namespaces of the parent container unless
> otherwise
> the mask calls for new namespaces.
>
> CONTAINER_NEW_FS_NS
> CONTAINER_NEW_EMPTY_FS_NS
> CONTAINER_NEW_CGROUP_NS [root only]
> CONTAINER_NEW_UTS_NS
> CONTAINER_NEW_IPC_NS
> CONTAINER_NEW_USER_NS
> CONTAINER_NEW_PID_NS
> CONTAINER_NEW_NET_NS
>
> Other flags include:
>
> CONTAINER_KILL_ON_CLOSE
> CONTAINER_CLOSE_ON_EXEC
>
> Note that I've added a pointer to the current container to
> task_struct.
> This doesn't make the nsproxy pointer redundant as you can still make
> new
> namespaces with clone().
>
> I've also added a list_head to task_struct to form a list in the
> container
> of its member processes. This is convenient, but redundant since the
> code
> could iterate over all the tasks looking for ones that have a
> matching
> task->container.
>
> It might make sense to use fsconfig() to configure the container:
>
> fsconfig(cfd, FSCONFIG_SET_NAMESPACE, "user", NULL, userns_fd);
> fsconfig(cfd, FSCONFIG_SET_NAMESPACE, "mnt", NULL, mntns_fd);
> fsconfig(cfd, FSCONFIG_SET_FD, "rootfs", NULL, root_fd);
> fsconfig(cfd, FSCONFIG_CMD_CREATE_CONTAINER, NULL, NULL, 0);
>
>
> ==================
> FUTURE DEVELOPMENT
> ==================
>
> (1) Setting up the container.
>
> A container would be created with, say:
>
> int cfd = container_create("fred", CONTAINER_NEW_EMPTY_FS_NS);
>
> Once created, it should then be possible for the supervising
> process
> to modify the new container. Mounts can be created inside of
> the
> container's namespaces:
>
> fsfd = fsopen("ext4", 0);
> fsconfig(fsfd, FSCONFIG_SET_CONTAINER, NULL, NULL, cfd);
> fsconfig(fsfd, FSCONFIG_SET_STRING, "source", "/dev/sda3", 0);
> fsconfig(fsfd, FSCONFIG_SET_FLAG, "user_xattr", NULL, 0);
> fsconfig(fsfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
> mfd = fsmount(fsfd, 0, 0);
>
> and then mounted into the namespace:
>
> move_mount(mfd, "", cfd, "/",
> MOVE_MOUNT_F_EMPTY_PATH |
> MOVE_MOUNT_T_CONTAINER_ROOT);
>
> Further mounts can be added by:
>
> move_mount(mfd, "", cfd, "proc", MOVE_MOUNT_F_EMPTY_PATH);
>
> Files and devices can be created by supplying the container fd
> as the
> dirfd argument:
>
> mkdirat(int cfd, const char *path, mode_t mode);
> mknodat(int cfd, const char *path, mode_t mode, dev_t dev);
> int fd = openat(int cfd, const char *path,
> unsigned int flags, mode_t mode);
>
> [*] Note that when using cfd as dirfd, the path must not contain
> a '/'
> at the front.
>
> Sockets, such as netlink, can be opened inside of the
> container's
> namespaces:
>
> int fd = container_socket(int cfd, int domain, int type,
> int protocol);
>
> This should allow management of the container's network
> namespace from
> outside.
>
> (2) Starting the container.
>
> Once all modifications are complete, the container's 'init'
> process
> can be started by:
>
> fork_into_container(int cfd);
>
> This precludes further external modification of the mount tree
> within
> the container. Before this point, the container is simply
> destroyed
> if the container fd is closed.
>
> (3) Waiting for the container to complete.
>
> The container fd can then be polled to wait for init process
> therein
> to complete and the exit code collected by:
>
> container_wait(int container_fd, int *_wstatus, unsigned int
> wait,
> struct rusage *rusage);
>
> The container and everything in it can be terminated or killed
> off:
>
> container_kill(int container_fd, int initonly, int signal);
>
> If 'init' dies, all other processes in the container are
> preemptively
> SIGKILL'd by the kernel.
>
> By default, if the container is active and its fd is closed, the
> container is left running and wil be cleaned up when its 'init'
> exits.
> The default can be changed with the CONTAINER_KILL_ON_CLOSE
> flag.
>
> (4) Supervising the container.
>
> Given that we have an fd attached to the container, we could
> make it
> such that the supervising process could monitor and override
> EPERM
> returns for mount and other privileged operations within the
> container.
>
> (5) Per-container keyring.
>
> Each container can point to a per-container keyring for the
> holding of
> integrity keys and filesystem keys for use inside the
> container. This
> would be attached:
>
> keyctl(KEYCTL_SET_CONTAINER_KEYRING, cfd, keyring)
>
> This keyring would be searched by request_key() after it has
> searched
> the thread, process and session keyrings.
>
> (6) Running different LSM policies by container. This might
> particularly
> make sense with something like Apparmor where different path-
> based
> rules might be required inside a container to inside the parent.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
Do we really need a new system call to set up containers? That would
force changes to all existing orchestration software.
Given that the main thing we want to achieve is to direct messages from
the kernel to an appropriate handler, why not focus on adding
functionality to do just that?
Is there any reason why a syscall to allow an appropriately privileged
process to add a keyring-specific message queue to its own
user_namespace and obtain a file descriptor to that message queue might
not work? That forces the container to use a daemon if it cares to
intercept keyring traffic, rather than worrying about the kernel
running request_key (in fact, it might make sense to allow a trivial
implementation of the daemon to be to just read the messages, parse
them and run request_key).
With such an implementation, the fallback mechanism could be to walk
back up the hierarchy of user_namespaces until a message queue is
found, and to invoke the existing request_key mechanism if not.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2019-02-17 18:57 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 16:07 [RFC PATCH 00/27] Containers and using authenticated filesystems David Howells
2019-02-15 16:07 ` David Howells
2019-02-15 16:07 ` [RFC PATCH 01/27] containers: Rename linux/container.h to linux/container_dev.h David Howells
2019-02-15 16:07 ` [RFC PATCH 02/27] containers: Implement containers as kernel objects David Howells
2019-02-15 16:07 ` David Howells
2019-02-17 18:57 ` Trond Myklebust [this message]
2019-02-17 18:57 ` Trond Myklebust
2019-02-17 19:39 ` James Bottomley
2019-02-17 19:39 ` James Bottomley
2019-02-19 16:56 ` Eric W. Biederman
2019-02-19 16:56 ` Eric W. Biederman
2019-02-19 23:03 ` David Howells
2019-02-19 23:03 ` David Howells
2019-02-20 14:23 ` Trond Myklebust
2019-02-20 14:23 ` Trond Myklebust
2019-02-19 23:06 ` David Howells
2019-02-20 2:20 ` James Bottomley
2019-02-20 2:20 ` James Bottomley
2019-02-20 3:04 ` Ian Kent
2019-02-20 3:04 ` Ian Kent
2019-02-20 3:46 ` James Bottomley
2019-02-20 3:46 ` James Bottomley
2019-02-20 4:42 ` Ian Kent
2019-02-20 4:42 ` Ian Kent
2019-02-20 6:57 ` Paul Moore
2019-02-20 6:57 ` Paul Moore
2019-02-19 23:13 ` David Howells
2019-02-19 23:13 ` David Howells
2019-02-19 23:55 ` Tycho Andersen
2019-02-19 23:55 ` Tycho Andersen
2019-02-20 2:46 ` Ian Kent
2019-02-20 2:46 ` Ian Kent
2019-02-20 13:26 ` Christian Brauner
2019-02-20 13:26 ` Christian Brauner
2019-02-20 13:26 ` Christian Brauner
2019-02-21 10:39 ` Ian Kent
2019-02-21 10:39 ` Ian Kent
2019-02-15 16:07 ` [RFC PATCH 03/27] containers: Provide /proc/containers David Howells
2019-02-15 16:07 ` David Howells
2019-02-15 16:07 ` [RFC PATCH 04/27] containers: Allow a process to be forked into a container David Howells
2019-02-15 17:39 ` Stephen Smalley
2019-02-15 17:39 ` Stephen Smalley
2019-02-19 16:39 ` Eric W. Biederman
2019-02-19 16:39 ` Eric W. Biederman
2019-02-19 23:16 ` David Howells
2019-02-19 23:16 ` David Howells
2019-02-15 16:07 ` [RFC PATCH 05/27] containers: Open a socket inside " David Howells
2019-02-19 16:41 ` Eric W. Biederman
2019-02-19 16:41 ` Eric W. Biederman
2019-02-15 16:08 ` [RFC PATCH 06/27] containers, vfs: Allow syscall dirfd arguments to take a container fd David Howells
2019-02-19 16:45 ` Eric W. Biederman
2019-02-19 16:45 ` Eric W. Biederman
2019-02-19 23:24 ` David Howells
2019-02-19 23:24 ` David Howells
2019-02-15 16:08 ` [RFC PATCH 07/27] containers: Make fsopen() able to create a superblock in a container David Howells
2019-02-15 16:08 ` David Howells
2019-02-15 16:08 ` [RFC PATCH 08/27] containers, vfs: Honour CONTAINER_NEW_EMPTY_FS_NS David Howells
2019-02-17 0:11 ` Al Viro
2019-02-15 16:08 ` [RFC PATCH 09/27] vfs: Allow mounting to other namespaces David Howells
2019-02-17 0:14 ` Al Viro
2019-02-15 16:08 ` [RFC PATCH 10/27] containers: Provide fs_context op for container setting David Howells
2019-02-15 16:09 ` [RFC PATCH 11/27] containers: Sample program for driving container objects David Howells
2019-02-15 16:09 ` David Howells
2019-02-15 16:09 ` [RFC PATCH 12/27] containers: Allow a daemon to intercept request_key upcalls in a container David Howells
2019-02-15 16:09 ` David Howells
2019-02-15 16:09 ` [RFC PATCH 13/27] keys: Provide a keyctl to query a request_key authentication key David Howells
2019-02-15 16:09 ` [RFC PATCH 14/27] keys: Break bits out of key_unlink() David Howells
2019-02-15 16:09 ` David Howells
2019-02-15 16:09 ` [RFC PATCH 15/27] keys: Make __key_link_begin() handle lockdep nesting David Howells
2019-02-15 16:09 ` David Howells
2019-02-15 16:09 ` [RFC PATCH 16/27] keys: Grant Link permission to possessers of request_key auth keys David Howells
2019-02-15 16:10 ` [RFC PATCH 17/27] keys: Add a keyctl to move a key between keyrings David Howells
2019-02-15 16:10 ` David Howells
2019-02-15 16:10 ` [RFC PATCH 18/27] keys: Find the least-recently used unseen key in a keyring David Howells
2019-02-15 16:10 ` David Howells
2019-02-15 16:10 ` [RFC PATCH 19/27] containers: Sample: request_key upcall handling David Howells
2019-02-15 16:10 ` David Howells
2019-02-15 16:10 ` [RFC PATCH 20/27] container, keys: Add a container keyring David Howells
2019-02-15 16:10 ` David Howells
2019-02-15 21:46 ` Eric Biggers
2019-02-15 21:46 ` Eric Biggers
2019-02-15 16:11 ` [RFC PATCH 21/27] keys: Fix request_key() lack of Link perm check on found key David Howells
2019-02-15 16:11 ` [RFC PATCH 22/27] KEYS: Replace uid/gid/perm permissions checking with an ACL David Howells
2019-02-15 16:11 ` David Howells
2019-02-15 17:32 ` Stephen Smalley
2019-02-15 17:32 ` Stephen Smalley
2019-02-15 17:39 ` David Howells
2019-02-15 17:39 ` David Howells
2019-09-30 16:39 ` Richard Haines
2019-09-30 16:39 ` Richard Haines
2019-02-15 16:11 ` [RFC PATCH 23/27] KEYS: Provide KEYCTL_GRANT_PERMISSION David Howells
2019-02-15 16:11 ` David Howells
2019-02-15 16:11 ` [RFC PATCH 24/27] keys: Allow a container to be specified as a subject in a key's ACL David Howells
2019-02-15 16:11 ` David Howells
2019-02-15 16:11 ` [RFC PATCH 25/27] keys: Provide a way to ask for the container keyring David Howells
2019-02-15 16:11 ` David Howells
2019-02-15 16:12 ` [RFC PATCH 26/27] keys: Allow containers to be included in key ACLs by name David Howells
2019-02-15 16:12 ` David Howells
2019-02-15 16:12 ` [RFC PATCH 27/27] containers: Sample to grant access to a key in a container David Howells
2019-02-15 16:12 ` David Howells
2019-02-15 22:36 ` [RFC PATCH 00/27] Containers and using authenticated filesystems James Morris
2019-02-15 22:36 ` James Morris
2019-02-19 16:35 ` Eric W. Biederman
2019-02-19 16:35 ` Eric W. Biederman
2019-02-19 16:35 ` Eric W. Biederman
2019-02-20 14:18 ` Christian Brauner
2019-02-20 14:18 ` Christian Brauner
2019-02-19 23:42 ` David Howells
2019-02-19 23:42 ` David Howells
2019-02-20 7:00 ` Paul Moore
2019-02-20 7:00 ` Paul Moore
2019-02-20 18:54 ` Steve French
2019-02-20 18:54 ` Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8c95213ae0981bd7af928902fcb34d6a9dedaa6f.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=rgb@redhat.com \
--cc=sfrench@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.