Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-19 Thread Adam Jackson
On Wed, 2020-02-19 at 13:27 +, Emil Velikov wrote: > + * As some point systemd-logind was introduced to orchestrate and delegate > + * master as applicable. It does so by opening the fd and passing it to users > + * while in itself logind a) does the set/drop master per users' request and > +

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-18 Thread Daniel Vetter
On Tue, Mar 17, 2020 at 1:26 PM Emil Velikov wrote: > > On Mon, 2 Mar 2020 at 18:29, Emil Velikov wrote: > > > > On Wed, 19 Feb 2020 at 13:27, Emil Velikov wrote: > > > > > > From: Emil Velikov > > > > > > This commit reworks the permission handling of the two ioctls. In > > > particular it enf

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-17 Thread Emil Velikov
On Mon, 2 Mar 2020 at 18:29, Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 13:27, Emil Velikov wrote: > > > > From: Emil Velikov > > > > This commit reworks the permission handling of the two ioctls. In > > particular it enforced the CAP_SYS_ADMIN check only, if: > > - we're issuing the ioctl

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-11 Thread Emil Velikov
On Mon, 9 Mar 2020 at 18:36, Emil Velikov wrote: > > On Mon, 9 Mar 2020 at 13:13, Emil Velikov wrote: > > > > OTOH, if applications exist that rely on drop-master failing in this > > > specific case, making drop-master succeed would break them. That might > > > include a buggy set-master path tha

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-09 Thread Emil Velikov
On Mon, 9 Mar 2020 at 13:13, Emil Velikov wrote: > > OTOH, if applications exist that rely on drop-master failing in this > > specific case, making drop-master succeed would break them. That might > > include a buggy set-master path that was written, but does not actually > > work because it was

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-09 Thread Emil Velikov
On Mon, 9 Mar 2020 at 08:38, Pekka Paalanen wrote: > > On Fri, 6 Mar 2020 18:51:22 + > Emil Velikov wrote: > > > On Fri, 6 Mar 2020 at 14:00, Pekka Paalanen wrote: > > > > > > On Wed, 19 Feb 2020 13:27:28 + > > > Emil Velikov wrote: > > > > > > > From: Emil Velikov > > > > > > > > > >

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-09 Thread Pekka Paalanen
On Fri, 6 Mar 2020 18:51:22 + Emil Velikov wrote: > On Fri, 6 Mar 2020 at 14:00, Pekka Paalanen wrote: > > > > On Wed, 19 Feb 2020 13:27:28 + > > Emil Velikov wrote: > > > > > From: Emil Velikov > > > > > > > ... > > > > > +/* > > > + * In the olden days the SET/DROP_MASTER ioctl

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-06 Thread Emil Velikov
On Fri, 6 Mar 2020 at 14:00, Pekka Paalanen wrote: > > On Wed, 19 Feb 2020 13:27:28 + > Emil Velikov wrote: > > > From: Emil Velikov > > > > ... > > > +/* > > + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when > > + * CAP_SYS_ADMIN was not set. This was used to preve

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-06 Thread Pekka Paalanen
On Wed, 19 Feb 2020 13:27:28 + Emil Velikov wrote: > From: Emil Velikov > ... > +/* > + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when > + * CAP_SYS_ADMIN was not set. This was used to prevent rogue applications > + * from becoming master and/or failing to relea

Re: [PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-02 Thread Emil Velikov
On Wed, 19 Feb 2020 at 13:27, Emil Velikov wrote: > > From: Emil Velikov > > This commit reworks the permission handling of the two ioctls. In > particular it enforced the CAP_SYS_ADMIN check only, if: > - we're issuing the ioctl from process other than the one which opened > the node, and > -

[PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

2020-02-19 Thread Emil Velikov
From: Emil Velikov This commit reworks the permission handling of the two ioctls. In particular it enforced the CAP_SYS_ADMIN check only, if: - we're issuing the ioctl from process other than the one which opened the node, and - we are, or were master in the past This ensures that we: - do no