On Tue, 12 Dec 2017 18:29:30 +0100 Rafał Krypa <[email protected]> wrote:
> Hi, 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. I ignored that glibc has this implementation. In that case I was wrong. Do you think that Smack settings of /dev/shm could help? > Maybe > you meant System V SHM segments, which indeed cannot be relabeled > under Smack? Yes I was thinking on shm_open of linux's "ipc" subsystem and shm security hooks. > 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
