lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 7 Mar 2014 11:09:39 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Lukasz Pawelczyk <havner@...il.com>
Cc:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	libvir-list@...hat.com, lxc-devel@...ts.linuxcontainers.org,
	systemd-devel@...ts.freedesktop.org,
	David Herrmann <dh.herrmann@...il.com>
Subject: Re: [systemd-devel] Suspending access to opened/active /dev/nodes
 during application runtime

On Fri, Mar 07, 2014 at 07:46:44PM +0100, Lukasz Pawelczyk wrote:
> Problem:
> Has anyone thought about a mechanism to limit/remove an access to a
> device during an application runtime? Meaning we have an application
> that has an open file descriptor to some /dev/node and depending on
> *something* it gains or looses the access to it gracefully (with or
> without a notification, but without any fatal consequences).
> 
> Example:
> LXC. Imagine we have 2 separate containers. Both running full operating
> systems. Specifically with 2 X servers. Both running concurrently of
> course. Both need the same input devices (e.g. we have just one mouse).

Stop right there.

If they "both" need an input device, then they should use the "shared"
input device stream, i.e. evdev.

And it goes the same for every type of device the kernel is exposing to
userspace, if you want to "share" them, then you need to work on
changing the kernel to be able to handle shared devices.

And odds are, you will get back a big "as-if" comment from the kernel
developers, as for almost all devices, they can't be shared, for very
good reasons.

So work down the list of devices you really need access to, and either
work to provide a way for the kernel to mediate them, or, work to only
have one "container" access to one device, and not have all containers
access to it at the same time.

This has been discussed many times in the past, on mailing lists and in
person at the Linux Plumbers conference last year.  This isn't a systemd
issue, it is a "you are using the kernel in ways it was not designed to
be used" issue.

good luck, you will need it...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists