[Cryptography] Swap space (Re: It's all K&R's fault)

Jerry Leichter leichter at lrw.com
Thu Apr 24 17:47:23 EDT 2014


On Apr 24, 2014, at 3:29 PM, Tom Mitchell <mitch at niftyegg.com> wrote:
> The fork(); exec() pair is mostly safe with the interesting
> detail bits about effective user and group ID transitions.
> The exec(ed) process only gets args but no data pages,
> open files and stuff.
This is false:  Any files open at the time of the exec() remain open.  That's now redirection is implemented, for example.  (It's possible on modern Unix implementations to mark a file "close on exec"; it's often important to do that.)  If by "args" you mean command line arguments, you can either let them be inherited (really, copied) or set them yourself, depending on the form of execXXX you use.

> However:
> Not all programs are exec(ed) in some cases the serious
> work of the process is done by the fork(ed) child.   That
> child does have ALL the data pages open files etc of the parent and
> in the case of security credentials that data persists too.
> Some programmers will carefully fiddle with effective UID and GID but
> might ignore data that trains along behind especially via lib*  data.
A fork()'ed process gets everything, other than file locks and pending signals (and the PID and PPID, to be technical).  It definitely gets the same UID, GID, terminal group ... all that stuff.

> There is no notification to the list of library activities on fork() so
> the programmer must know about and manage any sensitive data
> his libraries might own or need or no longer need.
I'm not sure what a "library activity" is.

If you're talking about threads, the interaction of threads with fork() is complex to begin with.  fork() in a thread produces a new process in which only the thread that called fork() is running.  (All the data corresponding to the other threads is there, but they are never run.)  If the next thing the process does is exec(), the left-over threads don't matter; but if the program wants to continue to run, things are messy (and if you want to remain in the standard-specified zone, *extremely* limited - you can only call async-signal-safe interfaces).  Pthreads provides pthread_atfork() as a callback to help manage this stuff.
                                                        -- Jerry


> 
> It is this library vector that may be interesting.
> 
> The Windows world is another pile of work.
> 
> And, I do not have it all sorted out.
> What other common OS models need to be inspected besides Android(s)?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
>  T o m    M i t c h e l l
> ×
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140424/d529d507/attachment.bin>


More information about the cryptography mailing list