9:49 p.m.
Begin forwarded message:
Date: Tue, 12 Dec 2017 12:44:46 +0200
From: Pekka Paalanen <ppaalanen(a)gmail.com>
To: José Bollo <jose.bollo(a)iot.bzh>
Cc: wayland-devel(a)lists.freedesktop.org, SMACK-discuss(a)lists.01.org
Subject: Re: Providing shared buffer for applications within Smack
environment
On Tue, 12 Dec 2017 11:00:23 +0100
José Bollo <jose.bollo(a)iot.bzh> 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?
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.
To achieve my goal I introduced a new environment variable intended
for sharing objects. This drives to the patch below [3]. The variable
is named XDG_RUNTIMESHARE_DIR here (but it can be changed because it
is not XDG in fact +_o)
I would rather not introduce any such variable. shm_open() should do
just fine. The important point which XDG_RUNTIME_DIR does not really
guarantee is that the backing store for the allocation is not a
physical disk but RAM.
I would really appreciate the feedbacks and ideas of fellow
developers
from here and there about what I did. Is it the right way to go? Can
it be up-streamed? Is it a valuable proposal for XDG too?
I believe shm_open() is the right way. If you wanted to be even more
modern, there is memfd_create syscall, but I don't we can generally
assume it is always available yet.
Thanks,
pq
Best regards
José Bollo
[1] www.automotivelinux.org
[2] https://www.kernel.org/doc/Documentation/security/Smack.txt
[3] patch below:
-----------------------------------------------------------------------
diff --git a/shared/os-compatibility.c b/shared/os-compatibility.c
index e19fb61b..7e93e818 100644
--- a/shared/os-compatibility.c
+++ b/shared/os-compatibility.c
@@ -157,6 +157,7 @@ os_create_anonymous_file(off_t size)
int fd;
int ret;
+ if (!(path = getenv("XDG_RUNTIMESHARE_DIR")))
path = getenv("XDG_RUNTIME_DIR");
if (!path) {
errno = ENOENT;
-----------------------------------------------------------------------
1741
days inactive
1741
days old
0 comments
1 participants
participants (1)
-
José Bollo