[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <470A0359.5090008@aitel.hist.no>
Date: Mon, 08 Oct 2007 12:15:53 +0200
From: Helge Hafting <helge.hafting@...el.hist.no>
To: gogi-k@...i.tv
CC: linux-kernel@...r.kernel.org
Subject: Re: One process with multiple user ids.
Giuliano Gagliardi wrote:
> On Tuesday 02 October 2007, Jan Engelhardt wrote:
>
>> On Oct 2 2007 12:56, Giuliano Gagliardi wrote:
>>
>>> I have a server that has to switch to different user ids, but because it
>>> does other complex things, I would rather not have it run as root. I only
>>> need the server to be able to switch to certain pre-defined user ids.
>>>
>> All you need is CAP_SETUID. Also see man setresuid,
>> where you could, I think, use saved_uid=0 if you do not
>> like to use real_uid=0 effective_uid=non-0.
>>
>
> But CAP_SETUID would let me change to any uid, would it not? I would like my
> process to have no possibility to change to any uid, except some predefined
> set, so that in case of a security hole only those uids could be compromised.
Why exactly do you need to change UID to a predefined set?
Do your app need to work with files owned by those users perhaps?
If so, consider filesystem solutions:
* make a group with all these users in, make the files rw for this group
or
* Use ACLs and let whatever UID your process use, have access to
the files in question.
Another approach if filesystem tricks don't fit your need:
Have a small process running as root. It should not do much
io or data processing, so its source is small and easy to audit. You
can make reasonably sure it has no security holes. This minimal app
will when needed:
* fork,
* set the correct UID for this particular job,
* exec the app that do work that is so complicated that
security holes might happen.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists