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

[Former user]

Original [issue 240](https://code.google.com/p/inferno-os/issues/detail?id=240) created by inferno-os on 2010-08-16T18:10:50.000Z:

/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.

[Former user]

Comment [#1](https://code.google.com/p/inferno-os/issues/detail?id=240#c1) originally posted by inferno-os on 2011-02-23T18:46:58.000Z:

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.

[Former user]

Comment [#2](https://code.google.com/p/inferno-os/issues/detail?id=240#c2) originally posted by inferno-os on 2011-02-24T23:20:41.000Z:

./Push 20110224-2312 committed changeset 488:ddbae373b71c