On Sun, Oct 05, 2014, Zac Medico wrote:
On 10/02/2014 07:32 PM, Steven J. Long wrote:
On Tue, Sep 30, 2014, Zac Medico wrote:
On Mon, Sep 29, 2014, Zac Medico wrote:
We control the shell code that launches the requested command, so we can
save the environment after the requested command
On 10/11/2014 12:06 AM, Steven J. Long wrote:
On Sun, Oct 05, 2014, Zac Medico wrote:
On 10/02/2014 07:32 PM, Steven J. Long wrote:
On Tue, Sep 30, 2014, Zac Medico wrote:
On Mon, Sep 29, 2014, Zac Medico wrote:
We control the shell code that launches the requested command, so we can
save
On Fri, Oct 03, 2014 at 05:01:20AM +0200, Peter Stuge wrote:
Steven J. Long wrote:
On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote:
The IPC implementation that I've suggested does not involve an SUID
helper, so it is much more secure. Security would rely on the permission
Steven J. Long wrote:
It's a lot more secure to have a single well-defined privileged trust
anchor (the privileged process) with a well-defined protocol, than to
have built-in privilege escalation which allows arbitrary actions.
You appear to have missed the point of what it does.
I
On 09/28/2014 09:23 PM, Steven J. Long wrote:
On Wed, Sep 24, 2014 at 09:51:31PM -0700, Zac Medico wrote:
On 07/09/2014 07:17 AM, Michał Górny wrote:
c) 'esudo' helper [3]. This is a more generic form of (2), with
support for other potential privilege changes.
..
I don't think we'd use the
On Wed, Sep 24, 2014 at 09:51:31PM -0700, Zac Medico wrote:
On 07/09/2014 07:17 AM, Michał Górny wrote:
c) 'esudo' helper [3]. This is a more generic form of (2), with
support for other potential privilege changes.
..
I don't think we'd use the reference 'sudo' impl. Rather some
