From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 12 Apr 2010 11:28:08 -0400 To: 9fans@9fans.net Message-ID: <7573881203f6654cee66c8bac1ee0529@kw.quanstro.net> In-Reply-To: References: <46914d2c-437d-406e-a928-123f4d09f9f7@u15g2000prd.googlegroups.com> <9c9e4b12769a946cad1659bb2a83fe0c@coraid.com> <8c05f41eb1f9a25d256bbe7caf738e82@kw.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] /sys/lib/newuser patch Topicbox-Message-UUID: fff0ad2e-ead5-11e9-9d60-3106f5b1d025 > > the problem you're addressing can't be addressed well through #Z. > > unix systems act differently than plan 9 ones do. there are a host > > of locking, etc. questions that #Z doesn't handle either.   it would be easier > > to use a plan 9 fs (ken fs, cwfs, fossil).  then you wouldn't need to > > deal with unix authentication. > > Probably true. However, I'm confident that there are ways to address > it -- and still, one of the cool things about 9vx is the local FS > access. When I was doing my 9vx autoprovisioner, the instances would > start in a chrooted sandbox, which was the best way I could figure to > deal with the permissioning issues at that point in time (without lots > o hacking). that is cool. but i think it's a mistake to get carried away. #Z just isn't a regular plan 9 file system. locks don't work. users and groups work differently. (and of course, 9vx is run by exactly 1 unix user so i don't see how pam helps.) authentication works differently, there's no append-only mode, etc. - erik