Hi,
On 2017-12-12 17:46, José Bollo wrote:
On Tue, 12 Dec 2017 13:28:58 +0200
Pekka Paalanen <[email protected]> wrote:
On Tue, 12 Dec 2017 12:08:43 +0100
José Bollo <[email protected]> wrote:
On Tue, 12 Dec 2017 12:44:46 +0200
Pekka Paalanen <[email protected]> wrote:
On Tue, 12 Dec 2017 11:00:23 +0100
José Bollo <[email protected]> wrote:
Hi all,
While working for AGL [1], I want to allow applications to
receive the buffers allocated by WESTON. The use of the
surfaces/buffers allocated by Weston is difficult when Smack is
activated.
Hi,
why do you need to make Weston allocate buffers? Why should those
buffers be accounted to Weston rather than a client that needs
them?
TBH, I've no idea of the how and the why but I know that at the end
clients of the shell call this allocator and that if nothing is
done, the file descriptor can't be passed to the client because of
Smack label.
I can check the reason if you like but it will take some time. It is
probably a window manager feature.
Hi,
I'm not too interested. If you can deliver the question for the
protocol extension designers to ponder on, that would be enough.
Usually we try to make the compositor take as little "blame" on
behalf of clients as possible. That includes all kinds of resource
allocations and processing.
E.g. Weston's screenshooting currently has the client allocate
buffers, pass them to Weston, and Weston writes into them, then
sends an event to say they are done.
There are valid use cases, I'm sure, just checking for the
obvious.
When these buffers are created, they are tagged with the smack
security label that depends on the security label of the service
WESTON and of the security label of the directory
XDG_RUNTIME_DIR when Smack transmutation allows it (see [2]).
For the sake of keeping things simple, I wanted to just tune
how the buffers are created. But I had to reach the issue that
XDG_RUNTIME_DIR is also used for socket end point and for lock,
leading to a opposition of requirements on the objects created
in XDG_RUNTIME_DIR: some of them are for sharing and some other
have to be under control.
The use of XDG_RUNTIME_DIR for allocating buffers is actually not
the best way. I think nowadays we should move on to using
shm_open() instead of creating temporary files in
XDG_RUNTIME_DIR.
From the Smack perspective, it probably means that the object is
tagged with the label of the process. This has implications for
Smacked systems.
I'm not too familiar with Smack. Would programs need to do something
special to be able to pass open file descriptors for other processes
to use? I can certainly understand protecting the content of
XDG_RUNTIME_DIR specifically, but what about in general, or for
shm_open() in particular? After all, shm_open() primarily meant for
inter-process sharing.
Not so simple at all! You are not able to share by default, conversely,
sharing must be explicitly stated by some rule.
shm_open allocates the IPC shm and attach it the security context of
the process that creates it. Any access to the shm requires an explicit
rule (or some few implicit rules like having the same label).
Using file and file system allows to create shared memory but with a
security label coming from the enclosing directory. This way the label
of the application (weston) can be still protected while the label of
the buffer is different (here it is shared to any application that
receive it because it is a kind of anonymous memory map).
This solution would not work with shm_open because the shm object is
sticked to the process. Even a privileged process can't change the
smack label of shm.
Conversely, I can mount XDG_RUNTIMESHARED_DIR with tmpfs to be sure
that there is absolutely nothing on "disk".
This statement about POSIX SHM and Smack is not true.
You get a file descriptor from shm_open() and nothing stops you from calling
fsetxattr(fd, XATTR_NAME_SMACK, ...) on it.
Since Linux glibc implements POSIX SHM as files in /dev/shm/ tmpfs, this isn't
really different than XDG_RUNTIMESHARED_DIR
from Smack point of view.
Maybe you meant System V SHM segments, which indeed cannot be relabeled under
Smack?
By the way, we have had a similar problem in Tizen with services creating POSIX
SHMs for applications, which then were
unable to write to the shared memory. Smack prohibited write access between
application label and service label.
For such use case we have created our own wrapper for shm_open() taking
additional argument - identifier of an app
that is supposed to receive the memory. SHM backing file is being relabeled by
privileged process to allow memory sharing.
Check and see if this is relevant in your case:
https://git.tizen.org/cgit/platform/core/security/security-manager/tree/src/include/app-runtime.h?h=tizen#n199
https://git.tizen.org/cgit/platform/core/security/security-manager/tree/src/client/client-security-manager.cpp?h=tizen#n1639
https://git.tizen.org/cgit/platform/core/security/security-manager/tree/src/common/service_impl.cpp?h=tizen#n1810
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
