From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7d59453c959b7754370ac8f4953956d3@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Novice question - run as other In-Reply-To: <200403171800.i2HI0jtq086906@adat.davidashen.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-pwpejlnbscgvathjxzpwvwjrrn" Date: Wed, 17 Mar 2004 13:14:29 -0500 Topicbox-Message-UUID: 345cb304-eacd-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-pwpejlnbscgvathjxzpwvwjrrn Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit You're confusing name space and semantics. It is indeed in the name space but the semantics of writing it is to change the state of the writer not everyone who can see the name space. Processes owned by different users can all share objects in the same name space. However reading or writing those objects can have different permissions and results for the different processes. If I where to unbind /dev, all processes in that name space would see that object disappear. The discontinuity/incongruity in Plan 9 is what an object can see about the process using it. Kernel objects (things implemented with #x for any x) can see the process and can adjust their behavior on its immediate state (this is especially true of #p). However anything that goes through 9P only sees the user's state by way of the messages sent to it. It can't tell anything about the particular process performing an action and can thus only adjust its semantics according to the user who actually bound the object into its name space (this action turns to an attach). --upas-pwpejlnbscgvathjxzpwvwjrrn Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed Mar 17 13:03:32 EST 2004 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Wed Mar 17 13:03:29 EST 2004 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id A540619B20; Wed, 17 Mar 2004 13:03:26 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 299BF19DC8; Wed, 17 Mar 2004 13:03:22 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 067E319DCC; Wed, 17 Mar 2004 13:02:59 -0500 (EST) Received: from adat.davidashen.net (unknown [217.113.20.242]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 0D05319DCC for <9fans@cse.psu.edu>; Wed, 17 Mar 2004 13:02:51 -0500 (EST) Received: from adat.davidashen.net (localhost.davidashen.net [127.0.0.1]) by adat.davidashen.net (8.12.8p1/8.12.8) with ESMTP id i2HI0j7b086907 for <9fans@cse.psu.edu>; Wed, 17 Mar 2004 22:00:45 +0400 (AMT) (envelope-from dvd@adat.davidashen.net) Received: (from dvd@localhost) by adat.davidashen.net (8.12.8p1/8.12.8/Submit) id i2HI0jtq086906 for 9fans@cse.psu.edu; Wed, 17 Mar 2004 22:00:45 +0400 (AMT) From: David Tolpin Message-Id: <200403171800.i2HI0jtq086906@adat.davidashen.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] Novice question - run as other In-Reply-To: Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 17 Mar 2004 22:00:45 +0400 (AMT) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Level: > > >@{echo -n none > '#c/user' ; while() {sleep 1} } > > >succeeds but does not change the owner of the process. Why? > > well, seems it would be bad if all you had to do to change userid was > echo into '#c/user' > > So, starting from that, the why should be apparent. The 'Why' was about a different issue. The question was why the C program behaves differently than the shell script. The C program just writes to #c/user to change the owner of the process. The answer is that writing to #c/user is special in the sense that although it is a part of namespace, it changes the state of the process space, which is only apparent if you look into the kernel source. A more general conclusion is that for tasks where writing to or reading from files reflects or affects process space, and not name space, rc is not suitable and C code must be written. I am now into the sources to understand which files in the namespace are actually not in it, but in the process space. David Tolpin http://davidashen.net/ --upas-pwpejlnbscgvathjxzpwvwjrrn--