On Mon, Aug 28, 2006 at 04:35:11PM -0500, Nicolas Williams wrote:
> 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.
I recommend against trying. When a program calls fork() is an
implementation detail of the highest order, and fixes using such a
library will be correspondingly fragile. The only way to determine
if an application of this fix is correct is to examine the source, at
which point you might as well modify it.
We can give you the status quo; your ability to go beyond without
modification will always depend on your application and its needs.
If you have an immutable application which needs to provide fault
isolation for its components, I recommend instructing SMF to ignore
core and signal failures for the application. If necessary, further
isolation from the effects of running the application in a service
can be achieved by using ctrun in its start method.
> 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.
The former is recipe for upset when the predicted behavior and actual
behavior diverge. The latter is terrifying.
> 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?
That's an interesting possibility.
> 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?
Strictly speaking, we already have that. It's the behavior you imply
that we don't: you don't want the second fork or a fork in the child
to create a contract. For that we have the following bugs:
5080413 one-shot active template option desired
5080414 option to clear active process contract template on child side of
fork() wanted
(These probably look familiar ;^)
If you are a simple application, you might not care about the
contracts once they are created, in which case a fix for
5076884 a mechanism for automatically abandoning process contracts on
creation
would also be useful.
Though using any of these requires application changes, those changes
will hopefully be very simple. I think it is a much saner approach
than trying to coax naive applications into being consumers of a
fault model they weren't written to be aware of.
Dave
