From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200301311535.h0VFZsY04092@zamenhof.cs.utwente.nl> To: 9fans@cse.psu.edu Subject: Re: [9fans] u9fs In-reply-to: Your message of "Tue, 28 Jan 2003 10:50:03 -0500." <37b786bb09656d2a3ea7cc27a27ad3ea@plan9.bell-labs.com> References: <37b786bb09656d2a3ea7cc27a27ad3ea@plan9.bell-labs.com> From: Axel Belinfante Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Jan 2003 16:35:54 +0100 Topicbox-Message-UUID: 4ae6201c-eacb-11e9-9e20-41e7f4b1d025 > There are changes to u9fs on sources that add support > for p9any as an authentication protocol. Thanks to Nigel. Great! Thanks! I reintegrated my u9fs modifications mentioned on the list before (for previous u9fs versions); I (think I) need them because my plan 9 user list differs from the unix user list, and these lists are managed by different people. They consist of a plan9-user to unix-user username mapping via a mapping file, and a hack to recognize '-lunixuser' in the attach name as a way to specify the unix-user name. I think(*) I like this flexibility, as I only use one plan 9 account but several unix ones. (*) it is all a bit experimental -- finding out what I want/need; right now I even don't rule out the potential conclusion that what I'm doing is too much, such that it can be removed again. My modifications worked nicely in combination with .rhosts authentication, because then a unix user had to explictly allow attach from plan 9 as his/her via an entry in .rhosts. With p9any this `limitation' is no longer there, allowing in principle to attach as any unix user (except root). To counter this, I added yet another modification, which kind of imitates the .rhosts file. With this modification, attach from plan9 only succeeds if the plan 9 user name is present in a .u9fs file in the home dir of the unix user as whom we try to attach. In particular, this means that to attach as unix user ``A'' it is no longer sufficient to just add a new user ``A'' on plan 9; user ``A'' on unix must explictly allow the attach via his .u9fs file. The code I have just works and still needs cleaning up (is still full of detailed debugging print statements); if there is interest I can post or put on the web. On a related note: I noticed that in the transition from 3ed to 4ed u9fs lost its -r (readonly) flag; are there particular reasons for that? I have been toying with the idea of allowing even greater control at the unix side, by allowing a ``readonly'' keyword with a user name in the .u9fs file. Suppose I would like to put readonly access back in, would it be sufficient to look at 3ed u9fs and ``copy'' from there? Or are there cases that I would miss? Axel.