Providing shared buffer for applications within Smack environment

[Pekka Paalanen]

On Tue, 12 Dec 2017 12:08:43 +0100
José Bollo <jose.bollo at iot.bzh> wrote:

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

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.

If this is something inherent to Smack, maybe we could have something
in upstream for it, but if it dependent on a particular Smack
configuration then I'm not sure it would make sense upstream.

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

memfd_create is a bit painful to use. I assume it still has no glibc
wrapper. It was introduced in Linux 3.17 and is specific to Linux.
OTOH, shm_open is a POSIX standard and we would need a shm_open path as
a fallback to memfd_open.


Thanks,
pq
-------------- 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/9a50e83d/attachment.sig>