Requiring root access for windowmanagers?

Requiring root access for windowmanagers?

[Koen Kooi]

Hi,

What's the consensus on requiring root access for running an OE built 
windowmanager?

Case in point: e-wm does 'renice -10', which only root is allow to do.

Proposal: remove the 'renice' so regular users can start a window 
manager as well.

regards,

Koen

Re: Requiring root access for windowmanagers?

[Koen Kooi]

On 28-11-08 13:20, Koen Kooi wrote:
> Hi,
>
> What's the consensus on requiring root access for running an OE built
> windowmanager?
>
> Case in point: e-wm does 'renice -10', which only root is allow to do.
>
> Proposal: remove the 'renice' so regular users can start a window
> manager as well.

The patch:

index e5a6502..7d472fa 100644
--- a/packages/e17/e-wm/enlightenment_start.oe
+++ b/packages/e17/e-wm/enlightenment_start.oe
@@ -5,5 +5,4 @@ if [ -r /etc/enlightenment/default_profile ]; then
    . /etc/enlightenment/default_profile
  fi

-renice -10 -p $$
  exec enlightenment_start $E_PROFILE
diff --git a/packages/e17/e-wm_svn.bb b/packages/e17/e-wm_svn.bb
index 1000ebf..1aff958 100644
--- a/packages/e17/e-wm_svn.bb
+++ b/packages/e17/e-wm_svn.bb
@@ -2,7 +2,7 @@ DESCRIPTION = "The Enlightenment Window Manager Version 17"
  DEPENDS = "eet evas ecore edje efreet edbus"
  LICENSE = "MIT BSD"
  PV = "0.16.999.043+svnr${SRCREV}"
-PR = "r21"
+PR = "r22"

Re: Requiring root access for windowmanagers?

[Carsten Haitzler]

On Fri, 28 Nov 2008 13:20:12 +0100 Koen Kooi <k.kooi@student.utwente.nl>
babbled:

> Hi,
> 
> What's the consensus on requiring root access for running an OE built 
> windowmanager?
> 
> Case in point: e-wm does 'renice -10', which only root is allow to do.
> 
> Proposal: remove the 'renice' so regular users can start a window 
> manager as well.

i did this specifically for performance. basically it makes things MUCH
smoother. the problem is thngs like frameworkd (python blob) in the background
eats a mountainload of cpu slowing startup down, making the system pretty bad
responsiveness-wise etc. i thought about it a bit and went "hey. on devices
the USER is king. the USER should always be obeyed ASAP and as smoothly as
possible". if some system daemon wants to eat cpu - it can take a back seat to
the user being obeyed. so upping e's priority helped immensely. suddenly
animations didn't stutter when launching apps or when background daemons decided
to chug along and eat lots of cpu etc.

as such you either lower the priority of all daemon procs - or raise (reduce
niceness) of the procs you want obeying the user asap.

so unless you have a better way to do this... (a normal user can still run -
the command just fails but the script marches on and you dont get a "less
nice" (higher priority) wm). so as such it wont stop a normal user. they just
lose smoothness.

of course i'm open to suggestions (note i do think you could have a much more
complex system but what i did was really simple and got the task done with no
breakage) :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com

Re: Requiring root access for windowmanagers?

[Stanislav Brabec]

Sat, 29 Nov 2008 01:04:22 +1100
Carsten Haitzler (The Rasterman) wrote:

> On Fri, 28 Nov 2008 13:20:12 +0100 Koen Kooi
> <k.kooi@student.utwente.nl> babbled:

> > What's the consensus on requiring root access for running an OE
> > built windowmanager?
> > 
> > Case in point: e-wm does 'renice -10', which only root is allow to
> > do.
> > 
> > Proposal: remove the 'renice' so regular users can start a window 
> > manager as well.
> 
> i did this specifically for performance. basically it makes things
> MUCH smoother.

I understand your trick - I do the same with video player if I want to
compile in parallel with DVD playback.

Running WM as root would increase any security hole to root access flaw.
I can see cleaner solutions:

1. Write a small SUID wrapper. Change priority, drop permissions, run
window manager.

2. Run WM as root and drop privileges after setting priority.

3. Use capabilities and enable CAP_SYS_NICE.

4. And finally, the best solution may be a different kernel scheduler.
But I don't follow the development there, so I don't know, whether
there is possible to find a good solution: "This process does not eat a
much CPU time, but it wants fast processing".

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Requiring root access for windowmanagers?

[Carsten Haitzler]

On Sat, 29 Nov 2008 21:52:47 +0100 Stanislav Brabec <utx@penguin.cz> babbled:

> Sat, 29 Nov 2008 01:04:22 +1100
> Carsten Haitzler (The Rasterman) wrote:
> 
> > On Fri, 28 Nov 2008 13:20:12 +0100 Koen Kooi
> > <k.kooi@student.utwente.nl> babbled:
> 
> > > What's the consensus on requiring root access for running an OE
> > > built windowmanager?
> > > 
> > > Case in point: e-wm does 'renice -10', which only root is allow to
> > > do.
> > > 
> > > Proposal: remove the 'renice' so regular users can start a window 
> > > manager as well.
> > 
> > i did this specifically for performance. basically it makes things
> > MUCH smoother.
> 
> I understand your trick - I do the same with video player if I want to
> compile in parallel with DVD playback.
> 
> Running WM as root would increase any security hole to root access flaw.
> I can see cleaner solutions:

as such though.. the openmoko distro runs everything as root - that's why i
really look at it and went "well.. in this case it'd work - for other cases
where its not root - well. no thing will break but you get no benefit".

> 1. Write a small SUID wrapper. Change priority, drop permissions, run
> window manager.

sure. shouldn't be hard.  i have one of these for playing with the realtime
scheduler (eg set scheduler to FIFO... this is fun for benchmarking!)
 
> 2. Run WM as root and drop privileges after setting priority.

wm would need code internally for this. this is possible. E already runs
sub-process at nice +1 so anything it launches will be of lower priority than
the wm (we can argue pros and cons forever and a day - but imho this is the
right thing. the managing infra here should get top priority for app switching,
launching feedback etc. etc.).

> 3. Use capabilities and enable CAP_SYS_NICE.

never touched this.

> 4. And finally, the best solution may be a different kernel scheduler.
> But I don't follow the development there, so I don't know, whether
> there is possible to find a good solution: "This process does not eat a
> much CPU time, but it wants fast processing".

that's pretty much everything :) the question is... when more than 1 of these
want the cpu "now"... who get's first-pick :)

as it is right now - non-root wm's don't break. they simply don't get a higher
priority. so this is relatively harmless. it just is non-beneficial for
non-root. the question is more - is there an agreement that this is a good
thing to do at all. i'd also argue X should be reduced in nice value (higher
priority) too so all refreshing, drawing, etc. takes priority over back-end
processing by apps.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com