Re: [Lpr-discuss] Re: I don't need no stinkin' setuid

[James A. <ja...@an...>]

Danek Duvall <dd...@en...> writes:

> I've spent the past hour and a half getting really confused about this
> problem, and then making myself believe I understand it.
> 
> Given: lpd needs to run with euid=lp to access on-disk database

 The main problem will be /dev/lp0 (you don't want just anyone to be
able to open the printer port and send stuff down it).

> Given: localderef needs to run with euid=jobuser to access user's files

 In general yes, in theory we could limit this to fuid (file uid). But
as far as I know only Linux supports that, so that would be extremely
unportable.

> Now, if we run lpd setuid lp and on demand when I start a print job, then
> it will retain the my real uid.  Whenever lpd then forks to exec a filter,
> it should call drop privileges -- setuid(getuid()) -- and become me again
> before calling exec().  Thus localderef runs as me without any fancy stuff
> going on.

 This means that lpd will have to synchronize between multiple versions
of itself running at once. You also have security concerns because it
means that the environment that lpd is running in is controlled by non
trusted users.

> Obviously, this will *not* work if lpd runs as a daemon with uid=lp, as it
> can neither fall back to the ruid nor setuid() to me.  In this case,
> localderef will need to be setuid or do the sudo thing.

 Here is what ben had planned on (from what I've read), but has the
problem that the user controls the environment for localderef ... one
approach might be to make it so that only the lpd user can execute
localdref (but still has the problem that if a user hacks the lpd
account then they gain a lot of privileges through localderefcan).

> Am I still on track?

 Yes.

-- 
# James Antill -- ja...@an...
:0:
* ^From: .*james@and\.org
/dev/null