Xegl lives!

[Adam Jackson]

On Sunday 29 May 2005 12:58, Jon Smirl wrote:
> On 5/29/05, Adam Jackson <ajax at nwnk.net> wrote:
> > You're predicating this on the assumption that the ability to break
> > broken monitors even further has something to do with the unix privilege
> > model.  I remain thoroughly unconvinced of this.
>
> During boot a hotplug driven, root priv app reads the DDC from the
> monitor. This DDC info is merged with user adjustments from /etc to
> end up with a list of valid modes.  The /etc merge is used to adjust
> for broken monitors. This list of valid modes is stored in the driver.
>
> User priv apps can read this list of valid modes and then pick one and
> set it via a sysfs variable. User priv apps can not set arbitrary
> modes. If you want a non-standard mode you need to be root so that you
> can edit the /etc file and add it to the list. Code for doing all of
> this has been in the Linux kernel for about four months now but it
> still has a few issues.
>
> Disconnecting the monitor and reconnecting it triggers a hotplug event
> which causes the mode list to be rebuilt. But this is not a common
> case.

This didn't answer the question.  You have stated before that the danger in 
allowing the driver to set arbitrary modes is that you can request a mode 
outside of what the monitor is capable of.  99.44% of monitors made in the 
past ten years will reject these modes (refuse to sync, blank screen).  The 
other ones are broken by design.

Setting the mode to something the monitor does not support, does not represent 
a privilege escalation.  It does not represent a way for the user to get 
access to data they do not normally have.  All it represents is the ability 
to turn broken hardware into non-functional hardware.

So as far as I can see, your assertion that userspace mode setting requires 
root depends solely on the assumption that it is the job of the privilege 
model to protect the hardware.  And it's not.  The job of the privilege model 
is to protect the software.

The only case I can see where you really do need to restrict this kind of 
access to the kernel is when modesetting for a given card is only available 
through the legacy x86 I/O space.  Even then that's not because it can damage 
the hardware, but because the only way to restrict access to the VGA range is 
with ioperm(3).

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050529/2996170a/attachment.pgp>