Xegl lives!

Adam Jackson ajax at nwnk.net
Sun May 29 12:47:40 PDT 2005


On Sunday 29 May 2005 14:32, Jon Smirl wrote:
> On 5/29/05, Adam Jackson <ajax at nwnk.net> wrote:
> > 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.
>
> Alan Cox specifically requested that setting arbitrary modes be
> restricted to root.

You do realize this is an appeal to authority, right?  And that other 
platforms are free to realize that this particular choice is bogus?

> > 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.
>
> I'm also a believer in the OS being there to stop an unprivileged user
> from destroying things. That includes burning out monitors and asking
> a disk to low level format itself. For example, should the OS prevent
> an unprivileged user from turning on disk level encryption? What if
> the user is a virus and doesn't tell you the password?

That's a case of the software wanting to protect the software.  If you forget 
the password, the OS won't boot; if you set a bad video mode, you can still 
ssh in and fix it.

At the risk of running this conversation in circles, my point was simply that 
running the server as non-root does not necessarily imply kernel-level mode 
setting.  I've heard your motivations (users are dumb and Alan says so) and I 
don't agree that they're sufficient.  If it were my OS, we wouldn't do mode 
setting in the kernel.

- 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/8b2a617d/attachment.pgp>


More information about the xorg mailing list