From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <15cc4d61b9ec75c7277a026702d4cc8d@collyer.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] remove files in /srv Date: Mon, 31 Jan 2005 20:44:11 -0800 From: geoff@collyer.net In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-bhcuqowfwriafnwjvdcyludwdn" Topicbox-Message-UUID: 3b7d7262-eace-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-bhcuqowfwriafnwjvdcyludwdn Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Would it make sense for cs to maintain the posted connections in /srv? Then only the hostowner has to do so. --upas-bhcuqowfwriafnwjvdcyludwdn Content-Type: message/rfc822 Content-Disposition: inline Received: from collyer.net ([216.240.55.164]) by collyer.net; Mon Jan 31 20:06:28 PST 2005 Received: from mail.cse.psu.edu ([130.203.4.6]) by collyer.net; Mon Jan 31 20:06:27 PST 2005 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id C859C63DF6 for ; Mon, 31 Jan 2005 23:06:25 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 7706063CA5 for <9fans@cse.psu.edu>; Mon, 31 Jan 2005 23:06:08 -0500 (EST) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24245-01-16 for <9fans@cse.psu.edu>; Mon, 31 Jan 2005 23:06:07 -0500 (EST) Received: from mx2.net.titech.ac.jp (mx2.net.titech.ac.jp [131.112.125.31]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id C375963C79 for <9fans@cse.psu.edu>; Mon, 31 Jan 2005 23:06:06 -0500 (EST) Received: (qmail 49480 invoked from network); 1 Feb 2005 04:06:05 -0000 Received: from unknown (HELO vc2.net.titech.ac.jp) (131.112.125.36) by mx2.net.titech.ac.jp with SMTP; 1 Feb 2005 04:06:05 -0000 Received: from unknown (HELO o.cc.titech.ac.jp) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 04:06:05 -0000 Received: from valinore.titech.ac.jp by mail-o.cc.titech.ac.jp (8.11.3/1.1.10.5/20Feb97-0455PM) id j11464q464824; Tue, 1 Feb 2005 13:06:04 +0900 (JST) Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] remove files in /srv From: YAMANASHI Takeshi <9.nashi@gmail.com> Date: Tue, 1 Feb 2005 13:05:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+geoff.9fans=collyer.net@cse.psu.edu Errors-To: 9fans-bounces+geoff.9fans=collyer.net@cse.psu.edu > This won't work well. 9fs alice creates /srv/alice as the user > who runs it, but if the connection is lost and someone else > runs 9fs alice, then they need permission to remove it and > replace it. They can post a new connection under another name like /srv/alice.username, can't they? There are many other important services now in /srv to trust users. I'm concerned for /srv/^(fossil fscons cs dns factotum) especially. # boot is excluded because of the special treatment -- --upas-bhcuqowfwriafnwjvdcyludwdn--