"private" request of prog(3) implemented by flag in the wrong place

[GoogleCodeExporter]

/prog provides an option, currently undocumented, similar to one on Plan 9: a 
"private" ctl request that prevents subsequent reading of presumably sensitive 
data through /prog. (it's understood that the protection extends only to the 
virtual machine.) it's to affect a process group, but unfortunately the 
"privatemem" flag in Pgrp is not the right place because Pgrp doesn't really 
correspond to a process group, but a name space (more or less). The flag needs 
to move to Progs, which does correspond to a group of related processes.

As things stand, running auth/factotum will prevent debugging of any other 
process sharing that name space, and so on.

Original issue reported on code.google.com by Charles....@gmail.com on 16 Aug 2010 at 6:10

[GoogleCodeExporter]

i ran into this.  a window manager starts factotum, and i cannot debug the 
window manager anymore.  attached patch seems to fix it (only tested the 
emu-version, the os-version has only been compiled).

is there more to it?
plan 9 clears the privatemem bit on exec.  i can't think of a similar point in 
time that is appropriate for clearing the bit in an inferno prog group.  we 
could let only a prog from the group clear it, but then such progs might be 
tricked into writing the unprivate ctl string to their prog ctl.  it seems good 
enough to never clear the privatemem bit.

Original comment by mechiel@ueber.net on 23 Feb 2011 at 6:46

Attachments:

• privatemem.diff

[GoogleCodeExporter]

./Push 20110224-2312
committed changeset 488:ddbae373b71c

Original comment by Charles....@gmail.com on 24 Feb 2011 at 11:20

• Changed state: Fixed