From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <140e7ec30802062352x26255504ha0d54596b954f8b8@mail.gmail.com> Date: Thu, 7 Feb 2008 16:52:28 +0900 From: sqweek To: 9fans@cse.psu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_24778_22383043.1202370748283" Subject: [9fans] 9pfuse adventure Topicbox-Message-UUID: 4ad10f76-ead3-11e9-9d60-3106f5b1d025 ------=_Part_24778_22383043.1202370748283 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline A while ago I ran acme at home to edit files at work using the neat u9fs over ssh trick[1]. I was impressed with how well it worked, so I thought I'd try it the other way. But obviously, my work machine isn't running plan9 so I can't use exactly the same approach. Also, my username at home is different to my username at work. Wouldn't have expected this to give me trouble, but p9p doesn't appear 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. At this point all the connections work: $ rm `namespace`/wren #wren is my home server $ srv sqweek.dnsdojo.org wren $ USER=sqweek /opt/plan9/src/cmd/o.9p -D ls wren/ <- Tversion tag 0 msize 8192 version '9P2000' -> Rversion tag 65535 msize 8192 version '9P2000' <- Tauth tag 0 afid 0 uname sqweek aname -> Rauth tag 0 qid (0000000000000001 0 A) <- Tversion tag 0 msize 8192 version '9P2000' -> Rversion tag 65535 msize 8192 version '9P2000' <- Tattach tag 0 fid 0 afid -1 uname sqweek aname -> Rattach tag 0 qid (0000000000000001 0 d) !adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org user: sqweek password: ! d-rwxr-xr-x M 0 root wheel 2048 Feb 3 23:01 etc d-r-xr-xr-x M 0 root wheel 512 Feb 7 15:14 kern d-rwxr-xr-x M 0 root wheel 512 Sep 4 2006 proc wren runs u9fs on netbsd, hence the root/wheel/etc. All is good, until I go to mount it using 9pfuse: $ USER=sqweek /opt/plan9/src/cmd/9pfuse/o.9pfuse -D `namespace`/wren $HOME/n/wren <- Tversion tag 0 msize 8192 version '9P2000' -> Rversion tag 65535 msize 8192 version '9P2000' <- Tattach tag 0 fid 0 afid -1 uname sqweek aname -> Rerror tag 0 ename fid unknown or out of range /opt/plan9/src/cmd/9pfuse/o.9pfuse: fsmount: fid unknown or out of range The thing that baffles me the most here (not that it takes much to baffle my rudimentry understanding of 9p) is that 9p and 9pfuse both send the exact same Tattach, 9p just precedes it with a Tauth and suddenly u9fs thinks fid 0 is valid. Isn't the client free to choose any fid it wants? The only reasonable suggestion I can come up with is that 9pfuse doesn't do auth, and u9fs gives a silly error. If I try with srv -a, subsequent attempts to access the socket using 9p or 9pfuse give "authentication failed": $ rm `namespace`/wren $ USER=sqweek /opt/plan9/src/cmd/o.srv -D -a sqweek.dnsdojo.org wren <- Tversion tag 65535 msize 8192 version '9P2000' -> Rversion tag 65535 msize 8192 version '9P2000' <- Tauth tag 1 afid 0 uname sqweek aname -> Rauth tag 1 qid (0000000000000001 0 A) <- Tread tag 1 fid 0 offset 0 count 4096 -> Rread tag 1 count 25 'p9sk1@sqweek.dnsdojo.org\0' <- Twrite tag 1 fid 0 offset 0 count 25 'p9sk1 sqweek.dnsdojo.org\0' -> Rwrite tag 1 count 25 <- Twrite tag 1 fid 0 offset 0 count 8 'eae63a67 1869ea20' -> Rwrite tag 1 count 8 <- Tread tag 1 fid 0 offset 0 count 141 -> Rread tag 1 count 141 '01737177 65656b00 00000000 00000000 00000000 00000000 00000000 00737177 65656b2e 646e7364 6f6a6f2e 6f726700 00000000 00000000 00000000 00000000' <- Twrite tag 1 fid 0 offset 0 count 85 '616d745f 42b7fd6d c7ff2799 fb85434e 147a35d6 ed1c60b6 172666fd 5dd47b3d dd1e45ef 90b11ebc cf207605 d7b5463d 55e0f6b4 75c11a40 1d2dac39 7fb09376' -> Rwrite tag 1 count 85 <- Tread tag 1 fid 0 offset 0 count 13 -> Rread tag 1 count 13 '7c5995b6 58424643 8a6135e2 00' $ USER=sqweek /opt/plan9/src/cmd/o.9p -D ls wren/ <- Tversion tag 0 msize 8192 version '9P2000' -> Rversion tag 65535 msize 8192 version '9P2000' <- Tauth tag 0 afid 0 uname sqweek aname -> Rerror tag 0 ename authentication not required <- Tattach tag 0 fid 0 afid -1 uname sqweek aname -> Rerror tag 0 ename authentication failed /opt/plan9/src/cmd/o.9p: mount: authentication failed $ USER=sqweek /opt/plan9/src/cmd/9pfuse/o.9pfuse -D `namespace`/wren $HOME/n/wren <- Tversion tag 0 msize 8192 version '9P2000' -> Rversion tag 65535 msize 8192 version '9P2000' <- Tattach tag 0 fid 0 afid -1 uname sqweek aname -> Rerror tag 0 ename authentication failed /opt/plan9/src/cmd/9pfuse/o.9pfuse: fsmount: authentication failed Finally, 9pfuse doesn't want to work in general. John Soros reported a similar problem[2] and on IRC it was discovered we're both running 64-bit linux, which may be related: $ 9pfuse `namespace`/plumb $HOME/n/:0.0/plumb $ cd $HOME/n/plumb $ ls unexpected open flags 0304000ls: .: Permission denied $ 9 ls unexpected open flags 0100000ls: .: Permission denied I'm not quite sure what GNU ls is adding into the mix, but 0100000 is the O_LARGEFILE flag, which ought to get filtered out in _fuseopen: /usr/local/plan9/src/cmd/9pfuse/main.c:564: flags &= ~(O_DIRECTORY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC); But for some reason isn't. It's certainly cpp related: $ 9c -E main.c |grep 'flags &=' flags &= ~3; flags &= ~(0200000|04000|0|02000000); flags &= ~01000; flags &= ~3; flags &= ~(0200000|04000|0); flags &= ~(0100|01000); And it turns out /usr/include/bits/fcntl.h #defines O_LARGEFILE to be 0 when __WORDSIZE == 64 (which I verified is the case). So 9pfuse looks fine, and the question becomes where the hell does ls pull 0100000 from... gdb nails it down to something in the fuse stack: 43 fd = open(name, umode); (gdb) print umode $5 = 0 (gdb) step unexpected open flags 0100000 44 if(fd >= 0){ (gdb) bt #0 p9open (name=0x4083cc ".", mode=) at open.c:44 #1 0x0000000000401a0d in ls (s=0x4083cc ".", multi=0) at ls.c:109 #2 0x0000000000401cc5 in p9main (argc=0, argv=0x7fffd9eea508) at ls.c:78 #3 0x00000000004030f9 in main (argc=4228044, argv=0x0) at main.c:10 Assuming I can trust gdb anyway, which is not always the case *sigh*. Well, I don't have the fuse source handy so this adventure will have to end here. Apologies for blogging up 9fans, but I'd appreciate any answers to my 9p questions. -sqweek [1] http://cm.bell-labs.com/wiki/plan9/Tip_o'_the_day/index.html [2] http://lists.cse.psu.edu/archives/9fans/2007-December/056900.html ------=_Part_24778_22383043.1202370748283 Content-Type: text/x-patch; name=USER.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_fcbhc9bu0 Content-Disposition: attachment; filename=USER.diff SW5kZXg6IHNyYy9jbWQvOXBzZXJ2ZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvcGxhbjkv c3JjL2NtZC85cHNlcnZlLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDAKZGlmZiAtdSAtcjEu NDAgOXBzZXJ2ZS5jCi0tLSBzcmMvY21kLzlwc2VydmUuYwkxMiBPY3QgMjAwNyAxNzowMTowMCAt MDAwMAkxLjQwCisrKyBzcmMvY21kLzlwc2VydmUuYwk2IEZlYiAyMDA4IDAzOjQ3OjM2IC0wMDAw CkBAIC00MjcsNyArNDI3LDggQEAKIAkJCQl9CiAJCQkJbS0+dHguYWZpZCA9IHhhZmlkOwogCQkJ CW0tPnR4LmFuYW1lID0geGFuYW1lOwotCQkJCW0tPnR4LnVuYW1lID0gZ2V0dXNlcigpOwkvKiB3 aGF0IHNydi5jIHVzZWQgKi8KKwkJCQlpZigobS0+dHgudW5hbWUgPSBnZXRlbnYoIlVTRVIiKSkg PT0gbmlsKQorCQkJCQltLT50eC51bmFtZSA9IGdldHVzZXIoKTsJLyogd2hhdCBzcnYuYyB1c2Vk ICovCiAJCQkJcmVwYWNrKCZtLT50eCwgJm0tPnRwa3QsIGMtPmRvdHUpOwogCQkJfQogCQkJYnJl YWs7CkluZGV4OiBzcmMvY21kL3Nydi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvcGxhbjkv c3JjL2NtZC9zcnYuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS42CmRpZmYgLXUgLXIxLjYgc3J2 LmMKLS0tIHNyYy9jbWQvc3J2LmMJMTIgT2N0IDIwMDcgMTc6MDE6MDkgLTAwMDAJMS42CisrKyBz cmMvY21kL3Nydi5jCTYgRmViIDIwMDggMDM6NDc6MzYgLTAwMDAKQEAgLTEzNiw3ICsxMzYsOCBA QAogCXR4LnR5cGUgPSBUYXV0aDsKIAl0eC50YWcgPSAxOwogCXR4LmFmaWQgPSBhZmlkOwotCXR4 LnVuYW1lID0gZ2V0dXNlcigpOworCWlmKCh0eC51bmFtZSA9IGdldGVudigiVVNFUiIpKSA9PSBu aWwpCisJCXR4LnVuYW1lID0gZ2V0dXNlcigpOwogCXR4LmFuYW1lID0gYW5hbWU7CiAJZG85cCgm dHgsICZyeCk7CiAJaWYocngudHlwZSA9PSBSZXJyb3IpewpJbmRleDogc3JjL2xpYjlwY2xpZW50 L2ZzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9wbGFuOS9zcmMvbGliOXBjbGllbnQvZnMu Yyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMApkaWZmIC11IC1yMS4xMCBmcy5jCi0tLSBzcmMv bGliOXBjbGllbnQvZnMuYwkyMyBKdWwgMjAwNiAwMjo1NTozMyAtMDAwMAkxLjEwCisrKyBzcmMv bGliOXBjbGllbnQvZnMuYwk2IEZlYiAyMDA4IDAzOjQ3OjQwIC0wMDAwCkBAIC02OSwxNCArNjks MTcgQEAKIENGc3lzKgogZnNtb3VudChpbnQgZmQsIGNoYXIgKmFuYW1lKQogeworCWNoYXIgKnVu YW1lOwogCUNGc3lzICpmczsKIAlDRmlkICpmaWQ7CiAKKwlpZigodW5hbWUgPSBnZXRlbnYoIlVT RVIiKSkgPT0gbmlsKQorCQl1bmFtZSA9IGdldHVzZXIoKTsKIAlmcyA9IGZzaW5pdChmZCk7CiAJ aWYoZnMgPT0gbmlsKQogCQlyZXR1cm4gbmlsOwogCi0JaWYoKGZpZCA9IGZzYXR0YWNoKGZzLCBu aWwsIGdldHVzZXIoKSwgYW5hbWUpKSA9PSBuaWwpeworCWlmKChmaWQgPSBmc2F0dGFjaChmcywg bmlsLCB1bmFtZSwgYW5hbWUpKSA9PSBuaWwpewogCQlfZnN1bm1vdW50KGZzKTsKIAkJcmV0dXJu IG5pbDsKIAl9CkluZGV4OiBzcmMvbGliOXBjbGllbnQvbnMuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxl OiAvY3ZzL3BsYW45L3NyYy9saWI5cGNsaWVudC9ucy5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAx LjQKZGlmZiAtdSAtcjEuNCBucy5jCi0tLSBzcmMvbGliOXBjbGllbnQvbnMuYwkxMyBKdWwgMjAw NSAxMDo1MDo0NCAtMDAwMAkxLjQKKysrIHNyYy9saWI5cGNsaWVudC9ucy5jCTYgRmViIDIwMDgg MDM6NDc6NDAgLTAwMDAKQEAgLTM4LDEzICszOCwxNiBAQAogQ0ZzeXMqCiBuc21vdW50KGNoYXIg Km5hbWUsIGNoYXIgKmFuYW1lKQogeworCWNoYXIgKnVuYW1lOwogCUNGc3lzICpmczsKIAlDRmlk ICpmaWQ7CiAKKwlpZigodW5hbWUgPSBnZXRlbnYoIlVTRVIiKSkgPT0gbmlsKQorCQl1bmFtZSA9 IGdldHVzZXIoKTsKIAlmcyA9IG5zaW5pdChuYW1lKTsKIAlpZihmcyA9PSBuaWwpCiAJCXJldHVy biBuaWw7Ci0JaWYoKGZpZCA9IGZzYXR0YWNoKGZzLCBuaWwsIGdldHVzZXIoKSwgYW5hbWUpKSA9 PSBuaWwpeworCWlmKChmaWQgPSBmc2F0dGFjaChmcywgbmlsLCB1bmFtZSwgYW5hbWUpKSA9PSBu aWwpewogCQlfZnN1bm1vdW50KGZzKTsKIAkJcmV0dXJuIG5pbDsKIAl9CkluZGV4OiBzcmMvbGli YXV0aC9mc2Ftb3VudC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvcGxhbjkvc3JjL2xpYmF1 dGgvZnNhbW91bnQuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xCmRpZmYgLXUgLXIxLjEgZnNh bW91bnQuYwotLS0gc3JjL2xpYmF1dGgvZnNhbW91bnQuYwkxMSBGZWIgMjAwNSAxNzowMToxNyAt MDAwMAkxLjEKKysrIHNyYy9saWJhdXRoL2ZzYW1vdW50LmMJNiBGZWIgMjAwOCAwMzo0Nzo0MCAt MDAwMApAQCAtOCwyMCArOCwyMyBAQAogQ0ZzeXMqCiBmc2Ftb3VudChpbnQgZmQsIGNoYXIgKmFu YW1lKQogeworCWNoYXIgKnVuYW1lOwogCUNGaWQgKmFmaWQsICpmaWQ7CiAJQXV0aEluZm8gKmFp OwogCUNGc3lzICpmczsKIAkKKwlpZigodW5hbWUgPSBnZXRlbnYoIlVTRVIiKSkgPT0gbmlsKQor CQl1bmFtZSA9IGdldHVzZXIoKTsKIAlmcyA9IGZzaW5pdChmZCk7CiAJaWYoZnMgPT0gbmlsKQog CQlyZXR1cm4gbmlsOwotCWlmKChhZmlkID0gZnNhdXRoKGZzLCBnZXR1c2VyKCksIGFuYW1lKSkg PT0gbmlsKQorCWlmKChhZmlkID0gZnNhdXRoKGZzLCB1bmFtZSwgYW5hbWUpKSA9PSBuaWwpCiAJ CWdvdG8gbm9hdXRoOwogCWFpID0gZnNhdXRoX3Byb3h5KGFmaWQsIGFtb3VudF9nZXRrZXksICJw cm90bz1wOWFueSByb2xlPWNsaWVudCIpOwogCWlmKGFpICE9IG5pbCkKIAkJYXV0aF9mcmVlQUko YWkpOwogbm9hdXRoOgotCWZpZCA9IGZzYXR0YWNoKGZzLCBhZmlkLCBnZXR1c2VyKCksIGFuYW1l KTsKKwlmaWQgPSBmc2F0dGFjaChmcywgYWZpZCwgdW5hbWUsIGFuYW1lKTsKIAlmc2Nsb3NlKGFm aWQpOwogCWlmKGZpZCA9PSBuaWwpewogCQlfZnN1bm1vdW50KGZzKTsKSW5kZXg6IHNyYy9saWJh dXRoL25zYW1vdW50LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9wbGFuOS9zcmMvbGliYXV0 aC9uc2Ftb3VudC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEKZGlmZiAtdSAtcjEuMSBuc2Ft b3VudC5jCi0tLSBzcmMvbGliYXV0aC9uc2Ftb3VudC5jCTExIEZlYiAyMDA1IDE3OjAxOjE4IC0w MDAwCTEuMQorKysgc3JjL2xpYmF1dGgvbnNhbW91bnQuYwk2IEZlYiAyMDA4IDAzOjQ3OjQwIC0w MDAwCkBAIC04LDIwICs4LDIzIEBACiBDRnN5cyoKIG5zYW1vdW50KGNoYXIgKm5hbWUsIGNoYXIg KmFuYW1lKQogeworCWNoYXIgKnVuYW1lOwogCUNGaWQgKmFmaWQsICpmaWQ7CiAJQXV0aEluZm8g KmFpOwogCUNGc3lzICpmczsKIAkKKwlpZigodW5hbWUgPSBnZXRlbnYoIlVTRVIiKSkgPT0gbmls KQorCQl1bmFtZSA9IGdldHVzZXIoKTsKIAlmcyA9IG5zaW5pdChuYW1lKTsKIAlpZihmcyA9PSBu aWwpCiAJCXJldHVybiBuaWw7Ci0JaWYoKGFmaWQgPSBmc2F1dGgoZnMsIGdldHVzZXIoKSwgYW5h bWUpKSA9PSBuaWwpCisJaWYoKGFmaWQgPSBmc2F1dGgoZnMsIHVuYW1lLCBhbmFtZSkpID09IG5p bCkKIAkJZ290byBub2F1dGg7CiAJYWkgPSBmc2F1dGhfcHJveHkoYWZpZCwgYW1vdW50X2dldGtl eSwgInByb3RvPXA5YW55IHJvbGU9Y2xpZW50Iik7CiAJaWYoYWkgIT0gbmlsKQogCQlhdXRoX2Zy ZWVBSShhaSk7CiBub2F1dGg6Ci0JZmlkID0gZnNhdHRhY2goZnMsIGFmaWQsIGdldHVzZXIoKSwg YW5hbWUpOworCWZpZCA9IGZzYXR0YWNoKGZzLCBhZmlkLCB1bmFtZSwgYW5hbWUpOwogCWZzY2xv c2UoYWZpZCk7CiAJaWYoZmlkID09IG5pbCl7CiAJCV9mc3VubW91bnQoZnMpOwo= ------=_Part_24778_22383043.1202370748283--