Providing shared buffer for applications within Smack environment

[José Bollo]

On Tue, 12 Dec 2017 12:44:46 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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?

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.

> 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.

> > 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.

Yes, a good point for shm.

> > 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.

Does it really matter as you already provide a suitable solution? Go
directly to memfd_create if its better.

Best regards
José

> 
> 
> 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;
> > -----------------------------------------------------------------------