From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 21 Mar 2008 11:08:04 +0100 From: John Soros To: 9fans@cse.psu.edu Message-ID: <20080321110804.111605c6@h4x> In-Reply-To: <140e7ec30802121140k6e05465rd13b90f98616650b@mail.gmail.com> References: <140e7ec30802062352x26255504ha0d54596b954f8b8@mail.gmail.com> <20080208192504.45B4E1E8C5B@holo.morphisms.net> <140e7ec30802121140k6e05465rd13b90f98616650b@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/QHFSiJPIYnFI_Ii/jCNnnMu" Subject: Re: [9fans] 9pfuse adventure Topicbox-Message-UUID: 7d77e152-ead3-11e9-9d60-3106f5b1d025 --MP_/QHFSiJPIYnFI_Ii/jCNnnMu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! well, i have been having this error for quite a while with 9pfuse. on amd64 linux (archlinux), i couldn't even ls a mounted directory, now that i have a 32 bit system, ls works, but cp doesn't (i have no idea if it hasanything to do with the arch, though). this is how i mount sources with p9p: $ 9fs sources $ 9 mount `namespace`/sources /tmp/sources then ls in a directory in /tmp/sources works, but when i try to copy, attached is the output. I'm open to testing whatever fixes you might suggest. regs John On Wed, 13 Feb 2008 04:40:27 +0900 sqweek wrote: > On Feb 9, 2008 4:25 AM, Russ Cox wrote: > > > provide any facility to attach as a different user. So, I modified the > > > attach strategy to look for a USER environment variable before falling > > > back on getuser(). I've attached the diff, hopefully I got everything. > > > > The name in the attach is almost just a comment. > > What matters is the name used inside the authentication > > protocol. (The name in the attach is really only there for > > non-authenticated connections.) So these changes > > shouldn't be necessary. > > Hm, I guess u9fs is misbehaving then? > > > This is the problem: you should never be prompted for a > > role=speakfor key. You should be prompted for a role=client key. > > If that happened correctly then I think things would have just > > worked. Try pre-loading a role=client key into factotum and > > see if that works better. > > I'm pretty sure I did have a role=client key in factotum in my > previous attempts, added by drawterm (I have a cpu/authserver on my > home network aswell, with the same user/pass/dom as my u9fs.key). I > reran the tests to be sure, the log is below. It turns out I only get > asked for a speakfor key when using my modified USER code, but it's > still the only way I've got a usable connection. > I had a quick look at u9fs and it does appear to be checking against > the Tattach uname in p9anyattach(), but if that check was failing I > should be getting "authentication failed" not "unknown user". > Um, but that was a pretty silly place to look anyway. There's only > one place "unknown user" is actually returned, and that is after > uname2user fails in rattach() (which was probably the original reason > for my USER hack). > I suspect there is no good solution here since if you called > uname2user() on the auth username, every user would connect with the > same permissions (I assume everyone connecting needs an auth key > matching /etc/u9fs.key?). Maybe it would work with tighter coupling > with the auth server? I never fully grasped the reason behind > /etc/u9fs.key... Otherwise, u9fs needs to be told remotely what uid to > use. > > $ 9p read factotum/ctl > key dom=sqweek.dnsdojo.org proto=p9sk1 role=client user=sqweek !password? > > $ rm `namespace`/wren > $ srv -a sqweek.dnsdojo.org wren > $ 9p ls wren/ > 9p: mount: unknown user > $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/ > /opt/plan9/src/cmd/o.9p: mount: unknown user > > $ rm `namespace`/wren > $ srv sqweek.dnsdojo.org wren > $ 9p ls wren/ > 9p: mount: unknown user > $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/ > !adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org > > -sqweek, thinking he should probably have set inferno up a long time ago --MP_/QHFSiJPIYnFI_Ii/jCNnnMu Content-Type: application/octet-stream; name=cp.output Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=cp.output JCBjcCAtciBzb3VyY2VzL3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcyAvaG9tZS9qb2hubnkv ZGV2L2F1ci90bXAKdW5leHBlY3RlZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fubm90IG9wZW4g YHNvdXJjZXMvcGxhbjkvc3lzL3NyYy9jbWQvdW5peC91OWZzL0xJQ0VOU0UnIGZvciByZWFkaW5n OiBQZXJtaXNzaW9uIGRlbmllZAp1bmV4cGVjdGVkIG9wZW4gZmxhZ3MgMDUwMDAwMGNwOiBjYW5u b3Qgb3BlbiBgc291cmNlcy9wbGFuOS9zeXMvc3JjL2NtZC91bml4L3U5ZnMvYXV0aG5vbmUuYycg Zm9yIHJlYWRpbmc6IFBlcm1pc3Npb24gZGVuaWVkCnVuZXhwZWN0ZWQgb3BlbiBmbGFncyAwNTAw MDAwY3A6IGNhbm5vdCBvcGVuIGBzb3VyY2VzL3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcy9h dXRocDlhbnkuYycgZm9yIHJlYWRpbmc6IFBlcm1pc3Npb24gZGVuaWVkCnVuZXhwZWN0ZWQgb3Bl biBmbGFncyAwNTAwMDAwY3A6IGNhbm5vdCBvcGVuIGBzb3VyY2VzL3BsYW45L3N5cy9zcmMvY21k L3VuaXgvdTlmcy9hdXRocmhvc3RzLmMnIGZvciByZWFkaW5nOiBQZXJtaXNzaW9uIGRlbmllZAp1 bmV4cGVjdGVkIG9wZW4gZmxhZ3MgMDUwMDAwMGNwOiBjYW5ub3Qgb3BlbiBgc291cmNlcy9wbGFu OS9zeXMvc3JjL2NtZC91bml4L3U5ZnMvY29udkQyTS5jJyBmb3IgcmVhZGluZzogUGVybWlzc2lv biBkZW5pZWQKdW5leHBlY3RlZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fubm90IG9wZW4gYHNv dXJjZXMvcGxhbjkvc3lzL3NyYy9jbWQvdW5peC91OWZzL2NvbnZNMkQuYycgZm9yIHJlYWRpbmc6 IFBlcm1pc3Npb24gZGVuaWVkCnVuZXhwZWN0ZWQgb3BlbiBmbGFncyAwNTAwMDAwY3A6IGNhbm5v dCBvcGVuIGBzb3VyY2VzL3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcy9jb252TTJTLmMnIGZv ciByZWFkaW5nOiBQZXJtaXNzaW9uIGRlbmllZAp1bmV4cGVjdGVkIG9wZW4gZmxhZ3MgMDUwMDAw MGNwOiBjYW5ub3Qgb3BlbiBgc291cmNlcy9wbGFuOS9zeXMvc3JjL2NtZC91bml4L3U5ZnMvY29u dlMyTS5jJyBmb3IgcmVhZGluZzogUGVybWlzc2lvbiBkZW5pZWQKdW5leHBlY3RlZCBvcGVuIGZs YWdzIDA1MDAwMDBjcDogY2Fubm90IG9wZW4gYHNvdXJjZXMvcGxhbjkvc3lzL3NyYy9jbWQvdW5p eC91OWZzL2N5Z3dpbi5jJyBmb3IgcmVhZGluZzogUGVybWlzc2lvbiBkZW5pZWQKdW5leHBlY3Rl ZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fubm90IG9wZW4gYHNvdXJjZXMvcGxhbjkvc3lzL3Ny Yy9jbWQvdW5peC91OWZzL2Rlcy5jJyBmb3IgcmVhZGluZzogUGVybWlzc2lvbiBkZW5pZWQKdW5l eHBlY3RlZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fubm90IG9wZW4gYHNvdXJjZXMvcGxhbjkv c3lzL3NyYy9jbWQvdW5peC91OWZzL2Rpcm1vZGVjb252LmMnIGZvciByZWFkaW5nOiBQZXJtaXNz aW9uIGRlbmllZAp1bmV4cGVjdGVkIG9wZW4gZmxhZ3MgMDUwMDAwMGNwOiBjYW5ub3Qgb3BlbiBg c291cmNlcy9wbGFuOS9zeXMvc3JjL2NtZC91bml4L3U5ZnMvZG9wcmludC5jJyBmb3IgcmVhZGlu ZzogUGVybWlzc2lvbiBkZW5pZWQKdW5leHBlY3RlZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fu bm90IG9wZW4gYHNvdXJjZXMvcGxhbjkvc3lzL3NyYy9jbWQvdW5peC91OWZzL2ZjYWxsLmgnIGZv ciByZWFkaW5nOiBQZXJtaXNzaW9uIGRlbmllZAp1bmV4cGVjdGVkIG9wZW4gZmxhZ3MgMDUwMDAw MGNwOiBjYW5ub3Qgb3BlbiBgc291cmNlcy9wbGFuOS9zeXMvc3JjL2NtZC91bml4L3U5ZnMvZmNh bGxjb252LmMnIGZvciByZWFkaW5nOiBQZXJtaXNzaW9uIGRlbmllZAp1bmV4cGVjdGVkIG9wZW4g ZmxhZ3MgMDUwMDAwMGNwOiBjYW5ub3Qgb3BlbiBgc291cmNlcy9wbGFuOS9zeXMvc3JjL2NtZC91 bml4L3U5ZnMvbWFrZWZpbGUnIGZvciByZWFkaW5nOiBQZXJtaXNzaW9uIGRlbmllZAp1bmV4cGVj dGVkIG9wZW4gZmxhZ3MgMDUwMDAwMGNwOiBjYW5ub3Qgb3BlbiBgc291cmNlcy9wbGFuOS9zeXMv c3JjL2NtZC91bml4L3U5ZnMvb2xkZmNhbGwuYycgZm9yIHJlYWRpbmc6IFBlcm1pc3Npb24gZGVu aWVkCnVuZXhwZWN0ZWQgb3BlbiBmbGFncyAwNTAwMDAwY3A6IGNhbm5vdCBvcGVuIGBzb3VyY2Vz L3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcy9vbGRmY2FsbC5oJyBmb3IgcmVhZGluZzogUGVy bWlzc2lvbiBkZW5pZWQKdW5leHBlY3RlZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fubm90IG9w ZW4gYHNvdXJjZXMvcGxhbjkvc3lzL3NyYy9jbWQvdW5peC91OWZzL3BsYW45LmgnIGZvciByZWFk aW5nOiBQZXJtaXNzaW9uIGRlbmllZAp1bmV4cGVjdGVkIG9wZW4gZmxhZ3MgMDUwMDAwMGNwOiBj YW5ub3Qgb3BlbiBgc291cmNlcy9wbGFuOS9zeXMvc3JjL2NtZC91bml4L3U5ZnMvcHJpbnQuYycg Zm9yIHJlYWRpbmc6IFBlcm1pc3Npb24gZGVuaWVkCnVuZXhwZWN0ZWQgb3BlbiBmbGFncyAwNTAw MDAwY3A6IGNhbm5vdCBvcGVuIGBzb3VyY2VzL3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcy9y YW5kb20uYycgZm9yIHJlYWRpbmc6IFBlcm1pc3Npb24gZGVuaWVkCnVuZXhwZWN0ZWQgb3BlbiBm bGFncyAwNTAwMDAwY3A6IGNhbm5vdCBvcGVuIGBzb3VyY2VzL3BsYW45L3N5cy9zcmMvY21kL3Vu aXgvdTlmcy9yZWFkbi5jJyBmb3IgcmVhZGluZzogUGVybWlzc2lvbiBkZW5pZWQKdW5leHBlY3Rl ZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fubm90IG9wZW4gYHNvdXJjZXMvcGxhbjkvc3lzL3Ny Yy9jbWQvdW5peC91OWZzL3JlbW90ZWhvc3QuYycgZm9yIHJlYWRpbmc6IFBlcm1pc3Npb24gZGVu aWVkCnVuZXhwZWN0ZWQgb3BlbiBmbGFncyAwNTAwMDAwY3A6IGNhbm5vdCBvcGVuIGBzb3VyY2Vz L3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcy9ydW5lLmMnIGZvciByZWFkaW5nOiBQZXJtaXNz aW9uIGRlbmllZAp1bmV4cGVjdGVkIG9wZW4gZmxhZ3MgMDUwMDAwMGNwOiBjYW5ub3Qgb3BlbiBg c291cmNlcy9wbGFuOS9zeXMvc3JjL2NtZC91bml4L3U5ZnMvc2FmZWNweS5jJyBmb3IgcmVhZGlu ZzogUGVybWlzc2lvbiBkZW5pZWQKdW5leHBlY3RlZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fu bm90IG9wZW4gYHNvdXJjZXMvcGxhbjkvc3lzL3NyYy9jbWQvdW5peC91OWZzL3N0cmVjcHkuYycg Zm9yIHJlYWRpbmc6IFBlcm1pc3Npb24gZGVuaWVkCnVuZXhwZWN0ZWQgb3BlbiBmbGFncyAwNTAw MDAwY3A6IGNhbm5vdCBvcGVuIGBzb3VyY2VzL3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcy9z dW4taW50dHlwZXMuaCcgZm9yIHJlYWRpbmc6IFBlcm1pc3Npb24gZGVuaWVkCnVuZXhwZWN0ZWQg b3BlbiBmbGFncyAwNTAwMDAwY3A6IGNhbm5vdCBvcGVuIGBzb3VyY2VzL3BsYW45L3N5cy9zcmMv Y21kL3VuaXgvdTlmcy90b2tlbml6ZS5jJyBmb3IgcmVhZGluZzogUGVybWlzc2lvbiBkZW5pZWQK dW5leHBlY3RlZCBvcGVuIGZsYWdzIDA1MDAwMDBjcDogY2Fubm90IG9wZW4gYHNvdXJjZXMvcGxh bjkvc3lzL3NyYy9jbWQvdW5peC91OWZzL3U5ZnMuYycgZm9yIHJlYWRpbmc6IFBlcm1pc3Npb24g ZGVuaWVkCnVuZXhwZWN0ZWQgb3BlbiBmbGFncyAwNTAwMDAwY3A6IGNhbm5vdCBvcGVuIGBzb3Vy Y2VzL3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcy91OWZzLmgnIGZvciByZWFkaW5nOiBQZXJt aXNzaW9uIGRlbmllZAp1bmV4cGVjdGVkIG9wZW4gZmxhZ3MgMDUwMDAwMGNwOiBjYW5ub3Qgb3Bl biBgc291cmNlcy9wbGFuOS9zeXMvc3JjL2NtZC91bml4L3U5ZnMvdTlmc2F1dGguaCcgZm9yIHJl YWRpbmc6IFBlcm1pc3Npb24gZGVuaWVkCnVuZXhwZWN0ZWQgb3BlbiBmbGFncyAwNTAwMDAwY3A6 IGNhbm5vdCBvcGVuIGBzb3VyY2VzL3BsYW45L3N5cy9zcmMvY21kL3VuaXgvdTlmcy91dGZydW5l LmMnIGZvciByZWFkaW5nOiBQZXJtaXNzaW9uIGRlbmllZAokCg== --MP_/QHFSiJPIYnFI_Ii/jCNnnMu--