On Thu, Sep 08, 2016 at 02:12:48PM +0000, Daniel Jurgens wrote: > On 9/7/2016 7:01 PM, ira.weiny wrote: > > On Tue, Sep 06, 2016 at 03:55:48PM -0600, Jason Gunthorpe wrote: > >> On Tue, Sep 06, 2016 at 08:35:56PM +0000, Daniel Jurgens wrote: > >> > >>> I think to control access to a VLAN for RoCE there would have to > >>> labels for GIDs, since that's how you select which VLAN to use. > >> Since people are talking about using GIDs for containers adding a GID > >> constraint for all technologies makes sense to me.. > >> > >> But rocev1 (at least mlx4) does not use vlan ids from the GID, the > >> vlan id is set directly in the id, so it still seems to need direct > >> containment. I also see vlan related stuff in the iwarp providers, so > >> they probably have a similar requirement. > >> > >>> required. RDMA device handle labeling isn't granular enough for > >>> what I'm trying to accomplish. We want users with different levels > >>> of permission to be able to use the same device, but restrict who > >>> they can communicate with by isolating them to separate partitions. > >> Sure, but maybe you should use the (device handle:pkey/vlan_id) as your > >> labeling tuple not (Subnet Prefix, pkey) > > Would "device handle" here specify the port? > > > > Ira > > It would have to include the port, but idea of using a device name for this is pretty ugly. <subnet_prefix,pkey> makes it very easy to write a policy that can be deployed widely. <device,port,pkey/vlan> could require many different policies depending on the configuration of each machine. > I agree that this seems weird. Using the Subnet prefix seems much safer in an IB/OPA environment. That would be my vote. Unfortunately I don't have enough knowledge of the net stat to know how this would work with RoCE or iWarp. > I've added Liran Liss, he devised the approach that's implemented. This would be a pretty big change, with worse usability so I'd like to get his feedback. > Sounds good, Ira _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
