So, as a follow-up to the "SMF deadlock?" and "SMF and child processes"
threads I wrote an LD_PRELOAD shared object that allows one to "target"
certain calls to fork() and put the resulting child processes into new
process contracts.

Selecting which calls to fork() should create new process contracts
turns out to be a non-trivial task and I don't yet see how to integrate
this LD_PRELOAD hack into OpenSolaris itself.

BUT, this could be a useful tool for anyone trying to create SMF
profiles for third party software that they can't modify, and/or a
porting tool for vendors/maintainers of such software.

Does the community think that this hack is worth posting?


This shared object allows one to select which fork() calls create new
process contracts by presence/absence of specific function from the
stack trace of the fork() call.

So, if you know that some daemon fork()s sessions from a function called
"doit()" then you can add this to the start method for that daemon:

LD_PRELOAD="$path_to_shim/newcontract.so $LD_PRELOAD" \
        NEWCT_CTID=`ps -o ctid= -p $$` \
        NEWCT_DO_FUNCS=doit \
        $daemon_program args...

The contract setup code is borrowed from the OpenSolaris sshd(1M).  The
code uses walkcontext(3C) and dladdr1(3C) to examine the stack.

(You shouldn't have to set NEWCT_CTID, and the fork() wrapper should
remove itself from LD_PRELOAD after creating a new contract, but for
some reason that I've not yet figured out calling putenv() from my
wrapper segfaults.)

As for RFEs for OpenSolaris, maybe we should consider an extension to
posix_spawn(3C) to specify that the spawned process should be in a new
process contract?  And/or maybe libcontract should provide utility
functions for fork()ing children in new process contracts, or for asking
that child of the next fork()/fork1()/vfork() (wherever it happens, say,
in system(3C)) be in a new process contract?

Nico
-- 

Reply via email to