Would it be possible to add to std.process.Config POSIX specific callback which would be called after fork()?

It is currently main blocker in switching dpaste-be from handmade process handling module to std.process.

It could look something like this.

struct Config {
     // current fields
     void delegate() posixCallback;
}

// ...

int i = fork();
if (i > 0)
{
//...
   if (config.posixCallback !is null)
        config.posixCallback();
//...
}

Such construct would allow for various child process manipulation, for instance
dropping root privileges or setting limits via setrmlimit.

Example:

config.posixCallback = {
    setguid(ourGUID);
    setgroups(ourGROUPS);
    setuid(ourUID);

    setrmlimit(NFORK, 123);
};


AFAIK we already have Windows specific flag related to spawning console for GUI apps.

I can make pull request ASAP when I get reasonable name for field.

Lars? ;)

On Thu, 06 Jun 2013 12:05:14 -0400, nazriel <spam@dzfl.pl> wrote:

> Would it be possible to add to std.process.Config POSIX specific callback which would be called after fork()?
>
> It is currently main blocker in switching dpaste-be from handmade process handling module to std.process.
>
> It could look something like this.
>
> struct Config {
>       // current fields
>       void delegate() posixCallback;
> }
>
> // ...
>
> int i = fork();
> if (i > 0)
> {
> //...
>     if (config.posixCallback !is null)
>          config.posixCallback();
> //...
> }
>
> Such construct would allow for various child process manipulation, for instance
> dropping root privileges or setting limits via setrmlimit.
>
> Example:
>
> config.posixCallback = {
>      setguid(ourGUID);
>      setgroups(ourGROUPS);
>      setuid(ourUID);
>
>      setrmlimit(NFORK, 123);
> };
>
>
> AFAIK we already have Windows specific flag related to spawning console for GUI apps.
>
> I can make pull request ASAP when I get reasonable name for field.
>
> Lars? ;)

I agree with the ability, but not with the interface.  If this is to be done, it should be at a lower level, not inside config.  Keep in mind that std.process is generalized for both Windows and Posix, with very minor differences.

-Steve

On Thursday, 6 June 2013 at 17:18:20 UTC, Steven Schveighoffer wrote:
> On Thu, 06 Jun 2013 12:05:14 -0400, nazriel <spam@dzfl.pl> wrote:
>
>> Would it be possible to add to std.process.Config POSIX specific callback which would be called after fork()?
>>
>> It is currently main blocker in switching dpaste-be from handmade process handling module to std.process.
>>
>> It could look something like this.
>>
>> struct Config {
>>      // current fields
>>      void delegate() posixCallback;
>> }
>>
>> // ...
>>
>> int i = fork();
>> if (i > 0)
>> {
>> //...
>>    if (config.posixCallback !is null)
>>         config.posixCallback();
>> //...
>> }
>>
>> Such construct would allow for various child process manipulation, for instance
>> dropping root privileges or setting limits via setrmlimit.
>>
>> Example:
>>
>> config.posixCallback = {
>>     setguid(ourGUID);
>>     setgroups(ourGROUPS);
>>     setuid(ourUID);
>>
>>     setrmlimit(NFORK, 123);
>> };
>>
>>
>> AFAIK we already have Windows specific flag related to spawning console for GUI apps.
>>
>> I can make pull request ASAP when I get reasonable name for field.
>>
>> Lars? ;)
>
> I agree with the ability, but not with the interface.  If this is to be done, it should be at a lower level, not inside config.  Keep in mind that std.process is generalized for both Windows and Posix, with very minor differences.
>
> -Steve

I am aware that std.process is generalized but I doubt such useful functionality which is usable on various Posixen is more disturbing than Windows-only suprpressConsole https://github.com/D-Programming-Language/phobos/blob/master/std/process.d#L954

But I was mistaken. Config is an enum not struct, so yeah, not worth changing it only for sake of posix callback.

So maybe module level variable?

module std.process;

// ...
void delegate() posixPostFork = null;
// ...


I would *really* love to see this implemented. It is really basic stuff for posixen.

Thanks a lot for responding Steven.

On Thursday, 6 June 2013 at 17:32:25 UTC, nazriel wrote:
> I am aware that std.process is generalized but I doubt such useful functionality which is usable on various Posixen is more disturbing than Windows-only suprpressConsole https://github.com/D-Programming-Language/phobos/blob/master/std/process.d#L954

I think there is a huge difference between a simple flag and the
ability to execute arbitrary code on one OS but not on another.
(When set, suppressConsole actually *eliminates* a difference in
the default behaviour of the two OS families.)

> But I was mistaken. Config is an enum not struct, so yeah, not worth changing it only for sake of posix callback.
>
> So maybe module level variable?
>
> module std.process;
>
> // ...
> void delegate() posixPostFork = null;
> // ...

Global state?  Don't want to go there...


> I would *really* love to see this implemented. It is really basic stuff for posixen.

It needs a good API and community support.  I don't think we
should introduce new functionality, that looks like it was bolted
on, because one person said they really needed it.

Is it possible to abstract the things you would like to do in
such a callback?  You mention privilege lowering as a use case.
Can we make an API that does this, and which modifies the
process' security context in Windows in an equivalent/similar
way, for instance?

are you talking about http://linux.die.net/man/3/pthread_atfork funktionality?

Am 06.06.2013 18:05, schrieb nazriel:
> Would it be possible to add to std.process.Config POSIX specific
> callback which would be called after fork()?
>
> It is currently main blocker in switching dpaste-be from handmade
> process handling module to std.process.
>
> It could look something like this.
>
> struct Config {
>        // current fields
>        void delegate() posixCallback;
> }
>
> // ...
>
> int i = fork();
> if (i > 0)
> {
> //...
>      if (config.posixCallback !is null)
>           config.posixCallback();
> //...
> }
>
> Such construct would allow for various child process
> manipulation, for instance
> dropping root privileges or setting limits via setrmlimit.
>
> Example:
>
> config.posixCallback = {
>       setguid(ourGUID);
>       setgroups(ourGROUPS);
>       setuid(ourUID);
>
>       setrmlimit(NFORK, 123);
> };
>
>
> AFAIK we already have Windows specific flag related to spawning
> console for GUI apps.
>
> I can make pull request ASAP when I get reasonable name for field.
>
> Lars? ;)
>

On Friday, 7 June 2013 at 05:59:24 UTC, Lars T. Kyllingstad wrote:
> On Thursday, 6 June 2013 at 17:32:25 UTC, nazriel wrote:
>> I am aware that std.process is generalized but I doubt such useful functionality which is usable on various Posixen is more disturbing than Windows-only suprpressConsole https://github.com/D-Programming-Language/phobos/blob/master/std/process.d#L954
>
> I think there is a huge difference between a simple flag and the
> ability to execute arbitrary code on one OS but not on another.
> (When set, suppressConsole actually *eliminates* a difference in
> the default behaviour of the two OS families.)
>

Depends on the point of view.
In my opinion both suppressConsole and posixCallack defines process details after process space is created.
The only difference is that suppressConsole is an exceptional switch to define behavior on exactly one platform (Windows) while posixCallback allows defying behavior on multiple POSIX compatible systems.


>> But I was mistaken. Config is an enum not struct, so yeah, not worth changing it only for sake of posix callback.
>>
>> So maybe module level variable?
>>
>> module std.process;
>>
>> // ...
>> void delegate() posixPostFork = null;
>> // ...
>
> Global state?  Don't want to go there...
>
Just proposition. I don't know what way you and Steven prefer.

>
>> I would *really* love to see this implemented. It is really basic stuff for posixen.
>
> It needs a good API and community support.  I don't think we
> should introduce new functionality, that looks like it was bolted
> on, because one person said they really needed it.

I understand. I just didn't except that this will be so controversial.
I thought that chopping off a lot of potential functionality on POSIX was just oversight, given that Windows has its own specific flag.

If such functionality isn't needed and I am the only one whining about it, let's just forget about whole topic.
I can live with my own more specialized implementation, I just thought it may be useful for others.

>
> Is it possible to abstract the things you would like to do in
> such a callback?  You mention privilege lowering as a use case.

My use cases are privilege lowering and setting up process limits (on per process basics).
But my point was that post-fork callback opens the window of additional process tuning and other possibilities, like dumping memory map or whatever user may want to do.

> Can we make an API that does this, and which modifies the
> process' security context in Windows in an equivalent/similar
> way, for instance?

I think we can, but then it closes various opportunities on POSIX.
I'm not that much experienced with Windows to be honest, but I think it is possible to switch user, but not possible to set per process limits (at least not possible on non-Server versions of Windows).

Again, I am not forcing anything on you or Steven.
I am asking you for opinion on something I find useful because you are the experts and I really like your work on new std.process

Best regards,
Damian Ziemba

On Friday, 7 June 2013 at 07:57:07 UTC, nazriel wrote:
> Again, I am not forcing anything on you or Steven.
> I am asking you for opinion on something I find useful because you are the experts and I really like your work on new std.process

It's not up to us either.  If the community wants it, and it can be implemented in a seamless manner, it should be.

By the way, did you look at Dennis Luehring's suggestion?

  http://linux.die.net/man/3/pthread_atfork

This looks like just what you need and more, it is part of the POSIX standard, and as far as I can see it can be used together with std.process.  You just call pthread_atfork() before you call spawnProcess().

Am 07.06.2013 10:21, schrieb Lars T. Kyllingstad:
> On Friday, 7 June 2013 at 07:57:07 UTC, nazriel wrote:
>> Again, I am not forcing anything on you or Steven.
>> I am asking you for opinion on something I find useful because
>> you are the experts and I really like your work on new
>> std.process
>
> It's not up to us either.  If the community wants it, and it can
> be implemented in a seamless manner, it should be.
>
> By the way, did you look at Dennis Luehring's suggestion?
>
>     http://linux.die.net/man/3/pthread_atfork
>
> This looks like just what you need and more, it is part of the
> POSIX standard, and as far as I can see it can be used together
> with std.process.  You just call pthread_atfork() before you call
> spawnProcess().
>

maybe

http://sourceware.org/pthreads-win32/

or this nice fork
https://github.com/GerHobbelt/pthread-win32

can give a hint how pthread_atfork can "work" under windosw
and show a way how to unifie the idea for both worlds

On Friday, 7 June 2013 at 06:27:32 UTC, dennis luehring wrote:
> are you talking about http://linux.die.net/man/3/pthread_atfork funktionality?
>

Very interesting. That may be exactly what I need.
I will try this out and see how does it play with std.process.

Thanks a lot!

On Friday, 7 June 2013 at 08:21:32 UTC, Lars T. Kyllingstad wrote:
> On Friday, 7 June 2013 at 07:57:07 UTC, nazriel wrote:
>> Again, I am not forcing anything on you or Steven.
>> I am asking you for opinion on something I find useful because you are the experts and I really like your work on new std.process
>
> It's not up to us either.  If the community wants it, and it can be implemented in a seamless manner, it should be.
>
> By the way, did you look at Dennis Luehring's suggestion?
>
>   http://linux.die.net/man/3/pthread_atfork
>
> This looks like just what you need and more, it is part of the POSIX standard, and as far as I can see it can be used together with std.process.  You just call pthread_atfork() before you call spawnProcess().

Yeah, now I noticed Dennis response.
It may be the solution to my issue yes.

Lovely POSIX, you can always count on it *G*

Thanks Dennis, Lars for help.
Sorry for the noise I caused.