Providing shared buffer for applications within Smack environment

[Pekka Paalanen]

On Tue, 12 Dec 2017 11:00:23 +0100
José Bollo <jose.bollo at 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;
> -----------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171212/3c2fe4da/attachment.sig>