Processes and mmap

Darren Tucker dtucker at zip.com.au
Fri Jul 4 08:42:14 EST 2008


Georgi Chulkov wrote:
>> Try Neils Provos' paper on privsep:
>> http://www.citi.umich.edu/u/provos/ssh/privsep.html
>>
>> If you still have questions after reading that, then please feel free to
>> ask here.
> 
> Thanks for the reference, that was a very good read. Unfortunately I cannot 
> quite understand the paragraph that stars at the end of page 4 ("Figure 3 
> shows an overview..."). In particular, I do not understand:
> 
> 1) Why is the shared address space "back" necessary?

For handling things like the zlib compression state.  This state 
includes things like compression dictionaries that are needed to 
decompress the data from the client, and their content changes over time.

Since zlib compression can be negotiated before the connection is 
authenticated, it means that the compression state has to be available 
to both the preauth and post-auth privsep slaves.

> 2) What does mm_share_sync do?

The shared memory allocator keeps accounting records of its allocations. 
  For the most part these are held in normal dynamically allocated memory.

When the first privsep process exits, it copies these accounting records 
to the shared memory area in a format that the new (post-auth) privsep 
process can unpack and use to continue managing the shared memory area.

> 3) What is the difference between mm using libc's malloc, as opposed to mm 
> using back which itself uses libc's malloc?

I'm not sure I follow this question.  If you allocate memory from "back" 
the memory you allocated is in the shared memory area.  The information 
about the allocation (the metadata) is in non-shared memory, and this 
metadata is what is copied by mm_share_sync.

> I will now try to figure out the source code that implements privilage 
> separation, and I will post any other questions I might have.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


More information about the openssh-unix-dev mailing list