All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Christopher James Halse Rogers <chris@cooperteam.net>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] xf86drm: Add drmIsMaster()
Date: Tue, 19 Feb 2019 21:40:52 +0100	[thread overview]
Message-ID: <20190219204052.GX2665@phenom.ffwll.local> (raw)
In-Reply-To: <20190124094504.GQ3271@phenom.ffwll.local>

On Thu, Jan 24, 2019 at 10:45:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2019 at 09:56:51AM +1300, Christopher James Halse Rogers wrote:
> > On 24 January 2019 6:18:32 am NZDT, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > >On Wed, 23 Jan 2019 at 04:39, Christopher James Halse Rogers
> > ><christopher.halse.rogers@canonical.com> wrote:
> > >>
> > >> We can't use drmSetMaster to query whether or not a drm fd is master
> > >> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
> > >>
> > >> Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
> > >> DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect
> > >> whether or not the fd is master.
> > >>
> > >> This is useful for code that might get master by open()ing the drm
> > >device
> > >> while no other master exists, but can't call drmSetMaster itself
> > >because
> > >> it's not running as root or is in a container, where container-root
> > >isn't
> > >> real-root.
> > >>
> > >> v2: Use the AUTH_MAGIC request rather than MODE_ATTACHMODE, as it's
> > >more
> > >>     clearly related to master status.
> > >>
> > >> Signed-off-by: Christopher James Halse Rogers
> > ><christopher.halse.rogers@canonical.com>
> > >> ---
> > >>  xf86drm.c | 15 +++++++++++++++
> > >>  xf86drm.h |  2 ++
> > >>  2 files changed, 17 insertions(+)
> > >>
> > >> diff --git a/xf86drm.c b/xf86drm.c
> > >> index 10df682b..adee5bd9 100644
> > >> --- a/xf86drm.c
> > >> +++ b/xf86drm.c
> > >> @@ -2741,6 +2741,21 @@ drm_public int drmDropMaster(int fd)
> > >>          return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, NULL);
> > >>  }
> > >>
> > >> +drm_public bool drmIsMaster(int fd)
> > >> +{
> > >> +        /* Detect master by attempting something that requires
> > >master.
> > >> +         *
> > >> +         * Authenticating magic tokens requires master and 0 is
> > >> +         * guaranteed to be an invalid magic number. Attempting this
> > >on
> > >> +         * a master fd will fail therefore fail with EINVAL because
> > >0 is
> > >> +         * invalid.
> > >> +         *
> > >> +         * A non-master fd will fail with EACCESS, as the kernel
> > >checks for
> > >> +         * master before attempting to do anything else.
> > >> +         */
> > >> +        return drmAuthMagic(fd, 0) == EINVAL;
> > >What magic value is valid, is a DRM implementation detail, which we
> > >don't need to depend upon.
> > >
> > >Instead we can check for EACCES, since we care if we have permissions
> > >- aka are we master.
> > >The function returns a negative errno, so I'd make this a:
> > >
> > >        return drmAuthMagic(fd, 0) != -EACCES;
> > >
> > >If you and Daniel agree, I'll squash this locally and push.
> > 
> > That's a much better idea, thanks!
> 
> I don't like checks for "something else happened", I much prefer checking
> for something specific. Hence == -EINVAL over != EACCESS. But I guess in
> this case here it doesn't matter.
> 
> We just need to make sure that the igt tests both ways, to make sure we'll
> never ever break this. I'd still prefer the current version, imo easier to
> write an igt to make sure it keeps working.

Since this landed now ... is the igt anywhere to make sure this keeps
working?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2019-02-19 20:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20  3:36 [PATCH libdrm] xf86drm: Add drmIsMaster() Christopher James Halse Rogers
2018-12-17 17:35 ` Emil Velikov
2018-12-17 17:59   ` Daniel Vetter
2018-12-18  6:07   ` Christopher James Halse Rogers
2019-01-22  2:26     ` Christopher James Halse Rogers
2019-01-22  7:55       ` Daniel Vetter
2019-01-23  4:38 ` [PATCH v2] " Christopher James Halse Rogers
2019-01-23 11:00   ` Daniel Vetter
2019-01-23 17:18   ` Emil Velikov
2019-01-23 20:56     ` Christopher James Halse Rogers
2019-01-24  9:45       ` Daniel Vetter
2019-02-19 20:40         ` Daniel Vetter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190219204052.GX2665@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@cooperteam.net \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.