> This way, we can call it easily in the code without troubles.
> I admittedly am a huge supporter of pledge() and would be happy
Then send the patch to the maintainer of the OpenBSD port.
Regards,
> Terminals accept arbitrary input, so pledge support could be a very desirable
> and well-suited feature.
Then add the lines yourself.
Regards,
On Mon, Jun 06, 2016 at 02:39:04PM +0200, FRIGN wrote:
> What it all brings up is the issue of IPC. Can you people suggest
> your favourite approach to IPC? If not, maybe we could look into
> writing a very simple library (name-suggestion "sippy" :P) which
> builds on top of UDS and implements a ve
On Mon, 06 Jun 2016, FRIGN wrote:
> What it all brings up is the issue of IPC. Can you people suggest
> your favourite approach to IPC? If not, maybe we could look into
> writing a very simple library (name-suggestion "sippy" :P) which
> builds on top of UDS and implements a very simple messaging
On Mon, 6 Jun 2016 13:36:14 +0200
Martin Kühne wrote:
Hey Martin,
> Having done my own research, no it can't. Also, the way it is designed
> is a rather silly approach to security which is much more revealing
> about today's idiotic way of writing software by including tens of
> millions of SLOC
On Mon, 06 Jun 2016, Martin Kühne wrote:
> Also, the way it is designed is a rather silly approach to security
> which is much more revealing about today's idiotic way of writing
> software by including tens of millions of SLOC of dependencies instead
> of doing the one thing for the one job.
Des
On Mon, 06 Jun 2016, Martin Kühne wrote:
> Can it somehow be made to keep its effect across the exec family of syscalls?
>
> cheers!
> mar77i
No. This is why pledging "stdio proc exec" is still quite dangerous. A
well-designed program may try separating this functionality into a
separate utility,
On Mon, Jun 6, 2016 at 1:19 PM, Martin Kühne wrote:
> Can it somehow be made to keep its effect across the exec family of syscalls?
>
Having done my own research, no it can't. Also, the way it is designed
is a rather silly approach to security which is much more revealing
about today's idiotic wa
On 6 June 2016 at 12:19, Martin Kühne wrote:
> Can it somehow be made to keep its effect across the exec family of syscalls?
My understanding is that one can pledge not to call exec, but if one
explicitly permits exec and it *is* called, the pledge no longer holds.
cls
Can it somehow be made to keep its effect across the exec family of syscalls?
cheers!
mar77i
On Mon, 06 Jun 2016, Martin Kühne wrote:
> I don't understand the purpose of pledge, since it's under the control
> of the programmer, but so is what the program does just as well. In
> what way is the programmer supposed to prevent himself from doing what
> they were going to do anyway?
>
> cheer
On 6 June 2016 at 11:51, Martin Kühne wrote:
> I don't understand the purpose of pledge, since it's under the control
> of the programmer, but so is what the program does just as well. In
> what way is the programmer supposed to prevent himself from doing what
> they were going to do anyway?
The
I don't understand the purpose of pledge, since it's under the control
of the programmer, but so is what the program does just as well. In
what way is the programmer supposed to prevent himself from doing what
they were going to do anyway?
cheers!
mar77i
On Mon, 06 Jun 2016 10:02:05 +0200
Kamil Cholewiński wrote:
Hey Kamil,
> The "problem" with pledge, is you have to let the program initialise
> completely, and only then drop the privileges. Otherwise it could've
> been implemented as a flag on the executable file.
You can also pledge multiple
On Mon, 06 Jun 2016, Ben Woolley wrote:
> But then, isn't that what config.h can do? Try it in config.h and see
> how you feel. A lot of OS-specific features are enabled from
> configuration in other software.
The "problem" with pledge, is you have to let the program initialise
completely, and on
15 matches
Mail list logo