On 8/15/2012 8:28 AM, Or Gerlitz wrote:
Currently, for an app to open a raw QP from user space, we (verbs)
require admin permission, for which we (Mellanox) got customer
feedback saying this is problematic on some of the environments.
Suppose we allow to user to provide source mac+vlan when
On Wed, 15 Aug 2012, Or Gerlitz wrote:
Currently, for an app to open a raw QP from user space, we (verbs) require
admin permission, for which we (Mellanox) got customer feedback saying this is
problematic on some of the environments.
Well yes it is but the kernel mod is a one line to get rid
On 15/08/2012 17:06, Christoph Lameter wrote:
On Wed, 15 Aug 2012, Or Gerlitz wrote:
Currently, for an app to open a raw QP from user space, we (verbs) require
admin permission, for which we (Mellanox) got customer feedback saying this is
problematic on some of the environments.
Well yes it
On Wed, Aug 15, 2012 at 04:28:38PM +0300, Or Gerlitz wrote:
Suppose we allow to user to provide source mac+vlan when creating
the QP or when modifying its state, and the HW can enforce that --
in that case I think its OK to remove that restriction e.g ala what
is allowed today with user space
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
Can you fix this by elevating the process with SELinux?
Chirstoph, do you think this would valid option from users standpoint?
Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
On Wed, 15 Aug 2012, Jason Gunthorpe wrote:
Can you fix this by elevating the process with SELinux?
Can SELinux be used to compromise security? How?
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Wed, 15 Aug 2012, Or Gerlitz wrote:
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
Can you fix this by elevating the process with SELinux?
Chirstoph, do you think this would valid option from users standpoint?
Sure. If SELinux can be used to compromise systems security (in a
