Re: [9fans] v9fs question
2009/7/13 Latchesar Ionkov lu...@ionkov.net: On Mon, Jul 13, 2009 at 2:24 AM, sqweeksqw...@gmail.com wrote: Anyway, note that if you auth you'll need supporting software from p9p also. Factotum and srv -a, in particular, then give v9fs a -o trans=unix. I don't think that auth is working with v9fs at all. The auth support got dropped accidentally with some of the changes, probably when access=user|any|uid was introduced. I.e. my fault. I didn't realise v9fs ever had auth support. Here is how I've been getting an authenticated mount for years: # create mountpoint $ n=$HOME/n $ mkdir -p $n/wren # need factotum running to do the dirty work $ factotum # srv -a posts a pre-authenticated socket in the p9p ns directory # wren is my fileserver $ srv -a wren !adding key: role=client proto=p9sk1 dom=sqweek.dnsdojo.org user[sqweek]: password: $ 9mount -i 'unix!/tmp/ns.sqweek.:0/wren' $n/wren (or) $ mount -t 9p -o uname=sqweek,trans=unix,noextend,dfltuid=$(id -u),dfltgid=$(id -g) /tmp/ns.sqweek.:0/wren $n/wren # I'm not sure if uname is strictly necessary $ 9bind $n/wren/home/sqweek/mail $HOME/sqweek/mail # various other binds Jorden mentioned it's a bad idea to let anyone mount anything because everyone shares the same namespace. 9mount does have some sanity checks for that environment, it will only let you mount over a directory you have write access to (and isn't sticky) or is under your home dir. Never really been field tested though :) Adding the support we had before the access= support is probably easy, but I would like to make it better and support authentication for multiple users. Still no idea what is the correct way. :( Any suggestions are welcome. Can't help you there - I'm not sure it makes sense to try and put factotum's functionality in the linux kernel... Is there some problem with the private namespace/individual user mount approach? -sqweek
Re: [9fans] v9fs question
this is at a bit of a tangent from the previous discussion, but something i've always wondered: why does the linux 9p mount syscall bother with IP addresses at all? isn't it sufficient just to provide a facility for mounting a file descriptor (like the plan 9 syscall) and have an auxiliary command do the actual dial, authentication, etc? wouldn't that be simpler and just as versatile?
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 1:08 PM, roger pepperogpe...@gmail.com wrote: this is at a bit of a tangent from the previous discussion, but something i've always wondered: why does the linux 9p mount syscall bother with IP addresses at all? isn't it sufficient just to provide a facility for mounting a file descriptor (like the plan 9 syscall) and have an auxiliary command do the actual dial, authentication, etc? wouldn't that be simpler and just as versatile? I perfectly agree. And I used to think this was how FUSE is working, but this has been only an uneducated guess.
Re: [9fans] v9fs question
On Jul 14, 2009, at 6:08 AM, roger peppe rogpe...@gmail.com wrote: this is at a bit of a tangent from the previous discussion, but something i've always wondered: why does the linux 9p mount syscall bother with IP addresses at all? isn't it sufficient just to provide a facility for mounting a file descriptor (like the plan 9 syscall) and have an auxiliary command do the actual dial, authentication, etc? This has always been an option. The tcp transport is there (and is default) because it is closest to the expected behavior for the naive Linux user. It is also there because at one time we used 9p as root (ala nfsroot direct option in the kernel). It's worth noting there are performance/efficency implications for using the fd transport (particularly for the non-socket fd case like sshsrv) as well as the unix named pipes transport -- but I don't have quantitative analysis of the differences as it's hard to get an apples to apples comparison. Anthony ligouri has shown some really promising numbers for a hybrid transport based on the Linux splice command. wouldn't that be simpler The code in question is mostly common, maybe 20 lines of code for each tcp and unix, so I think it's worth having them as options so that user space mount tools arent required.
Re: [9fans] v9fs question
On Jul 14, 2009, at 2:34 AM, sqweek sqw...@gmail.com wrote: 2009/7/13 Latchesar Ionkov lu...@ionkov.net: Adding the support we had before the access= support is probably easy, but I would like to make it better and support authentication for multiple users. Still no idea what is the correct way. :( Any suggestions are welcome. Can't help you there - I'm not sure it makes sense to try and put factotum's functionality in the linux kernel... Probably don't need factotum in kernel, Linux has a keyring facility that can be used to query userspace agents (like factotum). We'd just need the right hooks in v9fs and potentially a glue application to match the kernel keyring API. Is there some problem with the private namespace/individual user mount approach? Main annoyance is the lack of a proper srv device in Linux to facilitate sharing already open connections. This is t a problem for per-user mounts --- but is a problem for private namespaces. You can use p9p srv as mentioned elsewhere in this thread, but then you incur some additional overhead. -Eric
Re: [9fans] v9fs question
Main annoyance is the lack of a proper srv device in Linux to facilitate sharing already open connections. This is t a problem for per-user mounts --- but is a problem for private namespaces. You can use p9p srv as mentioned elsewhere in this thread, but then you incur some additional overhead. unless this is unmanagable slowness, wouldn't worring about performance at this stage only stand in the way of getting something working? - erik
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 8:23 AM, erik quanstromquans...@quanstro.net wrote: Main annoyance is the lack of a proper srv device in Linux to facilitate sharing already open connections. This is t a problem for per-user mounts --- but is a problem for private namespaces. You can use p9p srv as mentioned elsewhere in this thread, but then you incur some additional overhead. unless this is unmanagable slowness, wouldn't worring about performance at this stage only stand in the way of getting something working? Is something not working? My understanding of the situation is that many folks have a workable solution with p9p. The issues are ones of security, convenience and potentially performance. I'm not really a security expert, so I'll refrain from commenting on the first issue outside of the fact that there are concerns with the use of setuid applications, public mount points, and user-space managed connections to file systems (the latter only being a concern if the file system in question is the root partition). Outside of security, the option of tighter auth integration (via the keyring mechanism and fixing 9p.auth in v9fs) with the kernel module is primarily a convenience issue with a side-dish of performance. All that being said, I have no issues with the private mount approach, and have advocated it both via a paper (http://citeseer.ist.psu.edu/746023.html) and in the LKML mailing list discussions on removing privilege restrictions from the Linux mount system call. -eric
Re: [9fans] v9fs question
Hmm, I don't understand how this works. v9fs should issue its own Tversion and Tattach and discard the previously authenticated session, right? Or I am missing something? Thanks, Lucho On Tue, Jul 14, 2009 at 1:34 AM, sqweeksqw...@gmail.com wrote: 2009/7/13 Latchesar Ionkov lu...@ionkov.net: On Mon, Jul 13, 2009 at 2:24 AM, sqweeksqw...@gmail.com wrote: Anyway, note that if you auth you'll need supporting software from p9p also. Factotum and srv -a, in particular, then give v9fs a -o trans=unix. I don't think that auth is working with v9fs at all. The auth support got dropped accidentally with some of the changes, probably when access=user|any|uid was introduced. I.e. my fault. I didn't realise v9fs ever had auth support. Here is how I've been getting an authenticated mount for years: # create mountpoint $ n=$HOME/n $ mkdir -p $n/wren # need factotum running to do the dirty work $ factotum # srv -a posts a pre-authenticated socket in the p9p ns directory # wren is my fileserver $ srv -a wren !adding key: role=client proto=p9sk1 dom=sqweek.dnsdojo.org user[sqweek]: password: $ 9mount -i 'unix!/tmp/ns.sqweek.:0/wren' $n/wren (or) $ mount -t 9p -o uname=sqweek,trans=unix,noextend,dfltuid=$(id -u),dfltgid=$(id -g) /tmp/ns.sqweek.:0/wren $n/wren # I'm not sure if uname is strictly necessary $ 9bind $n/wren/home/sqweek/mail $HOME/sqweek/mail # various other binds Jorden mentioned it's a bad idea to let anyone mount anything because everyone shares the same namespace. 9mount does have some sanity checks for that environment, it will only let you mount over a directory you have write access to (and isn't sticky) or is under your home dir. Never really been field tested though :) Adding the support we had before the access= support is probably easy, but I would like to make it better and support authentication for multiple users. Still no idea what is the correct way. :( Any suggestions are welcome. Can't help you there - I'm not sure it makes sense to try and put factotum's functionality in the linux kernel... Is there some problem with the private namespace/individual user mount approach? -sqweek
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 1:34 AM, sqweeksqw...@gmail.com wrote: Can't help you there - I'm not sure it makes sense to try and put factotum's functionality in the linux kernel... Is there some problem with the private namespace/individual user mount approach? -sqweek I don't want to put the authentication in the kernel, but somehow to allow user space programs to create and manipulate authentication fids. One option would be to expose the afids in /proc or /sys, but then it is hard to figure out what mount they belong to. Another option is for every mount, v9fs serves mntpt/.afids directory at the top of the mountpoint. Or, as Ron suggested, just forget about multiple users and make it work for a single one. Thanks, Lucho
Re: [9fans] v9fs question
Is something not working? authentication? or doesn't that count? - erik
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 9:33 AM, Latchesar Ionkovlu...@ionkov.net wrote: Hmm, I don't understand how this works. v9fs should issue its own Tversion and Tattach and discard the previously authenticated session, right? Or I am missing something? It works because srv is serving its own (unauthenticated) version of the mount via 9p. I thought at one point in time we had something in there that bypassed tversion/tauth and that's how the amount stuff worked. But I don't see that code anymore, is that what got squashed with the new auth= stuff? -eric
Re: [9fans] v9fs question
I thought at one point in time we had something in there that bypassed tversion/tauth and that's how the amount stuff worked. But I don't see that code anymore, is that what got squashed with the new auth= stuff? has anyone written anything to deal with an exportfs connection on linux? - erik
Re: [9fans] v9fs question
Yes, that's what was removed. When the code was still there, the presence of the afid= option would prevent sending Tversion and would use the specified afid on Tattach. It is not hard to put it back. On Tue, Jul 14, 2009 at 8:54 AM, Eric Van Hensbergeneri...@gmail.com wrote: I thought at one point in time we had something in there that bypassed tversion/tauth and that's how the amount stuff worked. But I don't see that code anymore, is that what got squashed with the new auth= stuff?
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 10:01 AM, erik quanstromquans...@coraid.com wrote: I thought at one point in time we had something in there that bypassed tversion/tauth and that's how the amount stuff worked. But I don't see that code anymore, is that what got squashed with the new auth= stuff? has anyone written anything to deal with an exportfs connection on linux? I'm confused about what you are asking. -eric
Re: [9fans] v9fs question
has anyone written anything to deal with an exportfs connection on linux? I'm confused about what you are asking. if i have two plan 9 machines, i can import butts /mnt/consoles /n/consoles however, since import and exportfs run a special protocol in front of 9p, i don't think it's possible to do the same thing from a linux host. - erik
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 10:19 AM, erik quanstromquans...@coraid.com wrote: has anyone written anything to deal with an exportfs connection on linux? I'm confused about what you are asking. if i have two plan 9 machines, i can import butts /mnt/consoles /n/consoles however, since import and exportfs run a special protocol in front of 9p, i don't think it's possible to do the same thing from a linux host. Yeah, I don't think anyone is currently doing anything like that. I think for a while we were using aname in one of the early 9P servers to allow the mounting of a sub-hierarchy, but that's been gone for a while I think and still wouldn't do the exact same thing you are describing. -eric
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 4:08 AM, roger pepperogpe...@gmail.com wrote: why does the linux 9p mount syscall bother with IP addresses at all? isn't it sufficient just to provide a facility for mounting a file descriptor (like the plan 9 syscall) and have an auxiliary command do the actual dial, authentication, etc? The fd stuff has been in there in one form or another for 10 years. Just FYI. ron
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkovlu...@ionkov.net wrote: Yes, that's what was removed. When the code was still there, the presence of the afid= option would prevent sending Tversion and would use the specified afid on Tattach. It is not hard to put it back. That sounds nice to me, I would love to see it back. Was there a problem with it? ron
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 10:48 AM, ron minnichrminn...@gmail.com wrote: On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkovlu...@ionkov.net wrote: Yes, that's what was removed. When the code was still there, the presence of the afid= option would prevent sending Tversion and would use the specified afid on Tattach. It is not hard to put it back. That sounds nice to me, I would love to see it back. Was there a problem with it? I don't think there was a problem, I think it just got accidentally squashed. patches gladly accepted :) -eric
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 11:12 AM, erik quanstromquans...@coraid.com wrote: if i have two plan 9 machines, i can import butts /mnt/consoles /n/consoles however, since import and exportfs run a special protocol in front of 9p, i don't think it's possible to do the same thing from a linux host. Yeah, I don't think anyone is currently doing anything like that. I i would, if it existed. the current workarounds we have are quite horrendous. patches gladly accepted :) This is likely more of a wrapper application and server issue as you point out of course rather than something which is implemented in the kernel. -eric
Re: [9fans] v9fs question
if i have two plan 9 machines, i can import butts /mnt/consoles /n/consoles however, since import and exportfs run a special protocol in front of 9p, i don't think it's possible to do the same thing from a linux host. Yeah, I don't think anyone is currently doing anything like that. I i would, if it existed. the current workarounds we have are quite horrendous. - erik
Re: [9fans] v9fs question
this is at a bit of a tangent from the previous discussion, but something i've always wondered: why does the linux 9p mount syscall bother with IP addresses at all? isn't it sufficient just to provide a facility for mounting a file descriptor (like the plan 9 syscall) and have an auxiliary command do the actual dial, authentication, etc? wouldn't that be simpler and just as versatile? The v9fs driver lets you mount from a file descriptor. Is this what you're asking for? Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] v9fs question
2009/7/13 Eric Van Hensbergen eri...@gmail.com: On Mon, Jul 13, 2009 at 3:24 AM, sqweeksqw...@gmail.com wrote: Anyway, note that if you auth you'll need supporting software from p9p also. Factotum and srv -a, in particular, then give v9fs a -o trans=unix. Any chance we can get fossil integration into 9mount directly? Most of the code is already available in some p9p code that lucho wrote called amount. It would complicate build a bit because you need libraries from p9p, but perhaps it could be conditional compilation. I'm not too fond of the idea... It's not as though amount adds any new functionality over srv+mount[1], and I hate throwing more code at a problem when equivalent code exists elsewhere. Having to introduce a link time dependency on p9p doesn't help convince me either - the current arrangement seems to provide a decent seperation of responsibility. The mount.9p symlink sounds pretty reasonable though, I'll get around to that sometime. [1] actually back when I read over amount I even concluded that it used the same trick as srv -a just with a pipe instead of unix socket! failed to notice the Tversion/Tattach subtlety. is it really worth the coupling to go back to that approach? -sqweek
Re: [9fans] v9fs question
On Tue, Jul 14, 2009 at 2:05 PM, sqweeksqw...@gmail.com wrote: I'm not too fond of the idea... It's not as though amount adds any new functionality over srv+mount[1], and I hate throwing more code at a problem when equivalent code exists elsewhere. Having to introduce a link time dependency on p9p doesn't help convince me either - the current arrangement seems to provide a decent seperation of responsibility. The mount.9p symlink sounds pretty reasonable though, I'll get around to that sometime. [1] actually back when I read over amount I even concluded that it used the same trick as srv -a just with a pipe instead of unix socket! failed to notice the Tversion/Tattach subtlety. is it really worth the coupling to go back to that approach? Its not exactly the same. amount didn't use a pipe, it started the connection with an fd, did the auth and then passes the fd to the kernel to use. The use of the pipe adds extra copies on all data after authentication. This is the overhead involved with the srv approach that I mentioned. IMHO it is worth it for the performance. There's also the security implications of the srv approach, but I was never really much concerned with that angle. -eric
Re: [9fans] v9fs question
2009/7/14 Tim Newsham news...@lava.net: The v9fs driver lets you mount from a file descriptor. Is this what you're asking for? i was aware it allowed a mount of a file descriptor. in the interests of minimalism, i was wondering why it did anything else.
Re: [9fans] v9fs question
You'll notice it still tries mount(2) after stat(2) reveals that mount.9p doesn't exist. mount(8) always looks for a helper and will call it if it exists, but it doesn't fail when no helper is present. As others have said, mount(2) doesn't do name resolution, but by my reading that should give you an Invalid argument error instead of Protocol not supported. However the only place I see EPROTONOSUPPORT looks like an impossible code path... unless you have CONFIG_9P_FS enabled in your kernel but not CONFIG_NET_9P... which also shouldn't be possible with a current kernel. What version are you running? Anyway, note that if you auth you'll need supporting software from p9p also. Factotum and srv -a, in particular, then give v9fs a -o trans=unix. Oh, and to preempt the question why 9mount is not packaged as mount.9p - mount(8) requires that you are root or your mount target is in fstab with '-o user' before calling the helper, defeating the purpose of an SUID mount.9p. -sqweek 2009/7/12 Tim Newsham news...@lava.net: On Sat, 11 Jul 2009, Eric Van Hensbergen wrote: Hmmm, that's really new behavior-- never used to fail without mount helper. Can you give the exact error message? # strace -o trace.txt mount -t 9p thenewsh.com /mnt mount: Protocol not supported Trace.txt is attached with full details. I've tried several variants, such as thenewsh.com:/path with similar results. On Jul 11, 2009, at 1:46 PM, Tim Newsham news...@lava.net wrote: The documentation in the linux kernel says you merely mount -t 9p ipaddress /mntpoint this fails on my system since /sbin/mount tries to execute /sbin/mount.9p and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which ubunutu package should have this? If not, where I might find sources? Ironic since Ubuntu came with the 9p kernel module) Or should I be using a different mount program for the purpose? The linux Documentation/filesystems/9p.txt should probably be updated with more details, either way.
Re: [9fans] v9fs question
mount: Protocol not supported There was a time where you had to modprobe 9p2000 first. Should be worth a try.
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 3:24 AM, sqweeksqw...@gmail.com wrote: Anyway, note that if you auth you'll need supporting software from p9p also. Factotum and srv -a, in particular, then give v9fs a -o trans=unix. Any chance we can get fossil integration into 9mount directly? Most of the code is already available in some p9p code that lucho wrote called amount. It would complicate build a bit because you need libraries from p9p, but perhaps it could be conditional compilation. Oh, and to preempt the question why 9mount is not packaged as mount.9p - mount(8) requires that you are root or your mount target is in fstab with '-o user' before calling the helper, defeating the purpose of an SUID mount.9p. Well, IMHO it would be nice to have it named (or symlinked as) mount.9p folks who mount as root could get the helper automatically. This would be nice for the standard Linux admin who is mounting crap as root anyways and trips over the DNS resolution error because all they are used to is NFS which mount has always done DNS for. -eric
Re: [9fans] v9fs question
Anyway, note that if you auth you'll need supporting software from p9p also. Factotum and srv -a, in particular, then give v9fs a -o trans=unix. Would you mind documenting this a little more explicitly and posting it somewhere handy? I'm sure you've given enough hints here to make it work, but I can see that I have a merry documentation chase ahead of me :-) ++L
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 2:24 AM, sqweeksqw...@gmail.com wrote: Anyway, note that if you auth you'll need supporting software from p9p also. Factotum and srv -a, in particular, then give v9fs a -o trans=unix. I don't think that auth is working with v9fs at all. The auth support got dropped accidentally with some of the changes, probably when access=user|any|uid was introduced. I.e. my fault. Adding the support we had before the access= support is probably easy, but I would like to make it better and support authentication for multiple users. Still no idea what is the correct way. :( Any suggestions are welcome. Thanks, Lucho
Re: [9fans] v9fs question
If someone pulls together a verified HOWTO for the auth case, I'd be happy to add it to the Documentation/filesystems/9p.txt -eric On Mon, Jul 13, 2009 at 9:59 AM, lu...@proxima.alt.za wrote: Anyway, note that if you auth you'll need supporting software from p9p also. Factotum and srv -a, in particular, then give v9fs a -o trans=unix. Would you mind documenting this a little more explicitly and posting it somewhere handy? I'm sure you've given enough hints here to make it work, but I can see that I have a merry documentation chase ahead of me :-) ++L
Re: [9fans] v9fs question
Adding the support we had before the access= support is probably easy, but I would like to make it better and support authentication for multiple users. Still no idea what is the correct way. :( Any suggestions are welcome. I'm glad you brought this up because this is a conversation I wanted to see. I can think of several different ways to go about this: - nfs style: if you authenticate to the remote as root, you can speak for any of the uids you want to. This assumes a common mapping of users to uids across the machines. twist: root squash as an option, as per nfs. - single user: All files are presented as if owned by a single user. This need not be the user that was authenticated on the remote side. Any local user id would work. Perm checks are going to be done twice, anyway. Once locally (based on perms + the user id assigned to all files) and once remotely (on file server) based on the remote's idea of what user id you are (who you authenticated as). - multi-user authentication: A separate authenticated 9p channel is opened for each user that makes a request over the remote mount. This requires that some daemon have access to credentials to authenticate each user at least once. This daemon could be set up in advance or it could interactively request auth info as it goes. I think one obvious approach is to prime it with creds for a bunch of accounts and have it fall back to the single user case for all other accounts -- by mapping to some distinguished user such as nobody or guest or unauth9p. by the way, I think auth method offers some room for thought here, too. When talking with plan9 or inferno then p9sk1 or the inferno auth (whose name I forget) is the obvious choice. However, when talking just between several non-plan9 machines (ie. linux-linux) then other auth choices might make sense. How many 9p servers actually use auth? Most file servers are only accessed remotely through cpu or locally without auth, right? Lucho Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] v9fs question
Well, IMHO it would be nice to have it named (or symlinked as) mount.9p folks who mount as root could get the helper automatically. This would be nice for the standard Linux admin who is mounting crap as root anyways and trips over the DNS resolution error because all they are used to is NFS which mount has always done DNS for. If they invest their time to find out about the mount.9p command, won't they rather easily understand the DNS issue?
Re: [9fans] v9fs question
When I need remote access I nowadays use v9fs+ssh. Multi-user auth in kernel like you propose sounds nice and consistent, but too complicated. It doesn't fit linux, and thus an additional deamon would mean one more place of security relevant code prone to bugs. And even if this is only intended to be used locally I don't think it would be good enough for our distributed operating system's main network protocol. From a security (and perhaps simplicity) point of view userspace authentication sounds more reasonable to me, p9p together with something like fuse (even together with the new userspace hackery) or perhaps a single-user v9fs combined with inferno for doing the auth/crypt work seems a lot more reasonable to me than additional clever hackery from the plan9 side. Not sure if somebody has something like this working already...
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 3:44 PM, hiro23h...@googlemail.com wrote: Well, IMHO it would be nice to have it named (or symlinked as) mount.9p folks who mount as root could get the helper automatically. This would be nice for the standard Linux admin who is mounting crap as root anyways and trips over the DNS resolution error because all they are used to is NFS which mount has always done DNS for. If they invest their time to find out about the mount.9p command, won't they rather easily understand the DNS issue? Well, if someone installs the mount.9p package, then it just works -- at least at the same level of just works as CIFS and the other second-class distributed file systems for Linux. Its easier to tell someone to install a package than step them through installing and using a different command for mount than mount. -eric
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 4:45 PM, hiro23h...@googlemail.com wrote: When I need remote access I nowadays use v9fs+ssh. Multi-user auth in kernel like you propose sounds nice and consistent, but too complicated. It doesn't fit linux, and thus an additional deamon would mean one more place of security relevant code prone to bugs. While I agree with that being the state of things today, it doesn't mean we shouldn't push for better. Maybe the Glendix folks will make things consistent (and bug free). From a security (and perhaps simplicity) point of view userspace authentication sounds more reasonable to me, p9p together with something like fuse (even together with the new userspace hackery) or perhaps a single-user v9fs combined with inferno for doing the auth/crypt work seems a lot more reasonable to me than additional clever hackery from the plan9 side. Not sure if somebody has something like this working already... I have a variant using Inferno right now, mounting the file system directly from the stdin/stdout of the emu. Combined with private namespaces it provides a seemingly secure mechanism for accessing remote resources as well as providing local resources to remote cpu services. -eric
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 6:05 PM, Eric Van Hensbergeneri...@gmail.com wrote: On Mon, Jul 13, 2009 at 4:45 PM, hiro23h...@googlemail.com wrote: When I need remote access I nowadays use v9fs+ssh. Multi-user auth in kernel like you propose sounds nice and consistent, but too complicated. It doesn't fit linux, and thus an additional deamon would mean one more place of security relevant code prone to bugs. While I agree with that being the state of things today, it doesn't mean we shouldn't push for better. Maybe the Glendix folks will make things consistent (and bug free). We hope to. One of the reasons it would actually be unwise to let anyone mount anything now is that no one uses per-process namespaces. That's probably fine on your desktop, but not on a server where 20 people try to mount something under /mnt/foo or whatnot. On the security side, I helped get the plan9-style authentication device in the mainline kernel. It's in staging. I guess the PAM module is 90% done, but they need some help if anyone is interested. From a security (and perhaps simplicity) point of view userspace authentication sounds more reasonable to me, p9p together with something like fuse (even together with the new userspace hackery) or perhaps a single-user v9fs combined with inferno for doing the auth/crypt work seems a lot more reasonable to me than additional clever hackery from the plan9 side. Not sure if somebody has something like this working already... I have a variant using Inferno right now, mounting the file system directly from the stdin/stdout of the emu. Combined with private namespaces it provides a seemingly secure mechanism for accessing remote resources as well as providing local resources to remote cpu services. -eric
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote: We hope to. One of the reasons it would actually be unwise to let anyone mount anything now is that no one uses per-process namespaces. That's probably fine on your desktop, but not on a server where 20 people try to mount something under /mnt/foo or whatnot. Could we solve this by making private mounts the default (or only allowed) behavior? That's how I did it long ago: it took real effort to make a mount non-private. ron
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 6:16 PM, ron minnichrminn...@gmail.com wrote: On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote: We hope to. One of the reasons it would actually be unwise to let anyone mount anything now is that no one uses per-process namespaces. That's probably fine on your desktop, but not on a server where 20 people try to mount something under /mnt/foo or whatnot. Could we solve this by making private mounts the default (or only allowed) behavior? That's how I did it long ago: it took real effort to make a mount non-private. Not sure how easy or difficult this would be inside the kernel -- the central problem last time I looked at it was it was difficult to unshare namespace after the fork. Of course you could check to make sure you were not in the global namespace and error -- that should be easy enough. -eric
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergeneri...@gmail.com wrote: Not sure how easy or difficult this would be inside the kernel -- the central problem last time I looked at it was it was difficult to unshare namespace after the fork. Well, my mount command cheated. When you ran the mount command, it did a fork and set CLONE_NS. You were, at that point, in a private name space. Yes, ugly, but it certainly ensured a private mount. Of course you could check to make sure you were not in the global namespace and error -- that should be easy enough. That's a nice idea. You require users of the command to have a clean name space, or at least a non-global one, before you mount. That seems like a nice solution to the problem. ron
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 7:16 PM, ron minnichrminn...@gmail.com wrote: On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote: We hope to. One of the reasons it would actually be unwise to let anyone mount anything now is that no one uses per-process namespaces. That's probably fine on your desktop, but not on a server where 20 people try to mount something under /mnt/foo or whatnot. Could we solve this by making private mounts the default (or only allowed) behavior? It would be nice to fix up mounts so that you didn't need to be root and all that crap, and then make it the default, but I doubt Linus would let it fly. I get the feeling that private namespaces are viewed like chroots: a security feature no one but pros needs. Unfortunately not many linux devs seem to care about plan 9, and that has a negative impact on how much stuff can happen. Hopefully we'll gradually wear them down, or keep a minifork/patchset. That's how I did it long ago: it took real effort to make a mount non-private. ron
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 6:37 PM, ron minnichrminn...@gmail.com wrote: On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergeneri...@gmail.com wrote: Not sure how easy or difficult this would be inside the kernel -- the central problem last time I looked at it was it was difficult to unshare namespace after the fork. Well, my mount command cheated. When you ran the mount command, it did a fork and set CLONE_NS. You were, at that point, in a private name space. Yes, ugly, but it certainly ensured a private mount. Sure, and 9mount could do the same thing, but it would be nice to enforce it from the kernel somehow. -eric
Re: [9fans] v9fs question
It would be nice to fix up mounts so that you didn't need to be root and all that crap, and then make it the default, but I doubt Linus would let it fly. I get the feeling that private namespaces are viewed like chroots: a security feature no one but pros needs. Unfortunately not many linux devs seem to care about plan 9, and that has a negative impact on how much stuff can happen. Hopefully we'll gradually wear them down, or keep a minifork/patchset. i think if the linux folks really appreciated what one could do with namespaces, a number of the container bolt-on things could be implemented in terms of namespace. (then again, i have a feeling the same could be said of plan 9.) it's quite interesting to see how taking the seemingly- conservative approach at every turn can take you much further from v7 than even pretty radical breaks like plan 9. - erik
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 7:50 PM, erik quanstromquans...@quanstro.net wrote: It would be nice to fix up mounts so that you didn't need to be root and all that crap, and then make it the default, but I doubt Linus would let it fly. I get the feeling that private namespaces are viewed like chroots: a security feature no one but pros needs. Unfortunately not many linux devs seem to care about plan 9, and that has a negative impact on how much stuff can happen. Hopefully we'll gradually wear them down, or keep a minifork/patchset. i think if the linux folks really appreciated what one could do with namespaces, a number of the container bolt-on things could be implemented in terms of namespace. So much cruft would go right out the window if only it were accessible. (then again, i have a feeling the same could be said of plan 9.) Of course, everything has cruft. But Plan 9 is decent to imitate since it is less crufty. it's quite interesting to see how taking the seemingly- conservative approach at every turn can take you much further from v7 than even pretty radical breaks like plan 9. - erik Agreed.
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 6:41 PM, J.R. Maurojrm8...@gmail.com wrote: On Mon, Jul 13, 2009 at 7:16 PM, ron minnichrminn...@gmail.com wrote: On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote: We hope to. One of the reasons it would actually be unwise to let anyone mount anything now is that no one uses per-process namespaces. That's probably fine on your desktop, but not on a server where 20 people try to mount something under /mnt/foo or whatnot. Could we solve this by making private mounts the default (or only allowed) behavior? It would be nice to fix up mounts so that you didn't need to be root and all that crap, and then make it the default, but I doubt Linus would let it fly. I get the feeling that private namespaces are viewed like chroots: a security feature no one but pros needs. Unfortunately not many linux devs seem to care about plan 9, and that has a negative impact on how much stuff can happen. Hopefully we'll gradually wear them down, or keep a minifork/patchset. When things get further along we can do a coordinated assault :) We've got bits of mindshare spread out over different places including a couple of the major distributions, if things can be made optional they'll make it into mainline and then we just need to focus on education by presenting demos at places like OLS, Plumbers, and LCA -- and maybe get some good video podcast tutorials up on YouTube to get people wanting and using the features. Of course the main thing is finding a niche that needs the features and selling them on it. The focus on cloud computing and other cluster type solutions in mainstream computing may be helpful there. -eric
Re: [9fans] v9fs question
(then again, i have a feeling the same could be said of plan 9.) Of course, everything has cruft. But Plan 9 is decent to imitate since it is less crufty. not only is plan 9 cleaner, it's core ideas are all high quality, and one can understand it. so when it comes time to add one's own brand of cruft, it's easy to do. unfortunately plan 9 does not make good ideas any easier to come by. - erik
Re: [9fans] v9fs question
you need to find the niche and provide programs, which people can just use. Or you need to find the niche that lets other people write programs, and we're not where we need to be on that score. It's still too hard for people to write servers and there's no clear answer on which library to use. FUSE has done a great job in this area. ron
Re: [9fans] v9fs question
Could we solve this by making private mounts the default (or only allowed) behavior? I've wondered if there's enough context information that the fs driver could fake per-process mount points directly. For example, I mount v9fs on /n. Initially I have no remote mounts in there, but I have /n/ctl. I echo mount 1.2.3.4 foo to /n/ctl and now I have /n/foo which is served from 1.2.3.4 for my process, but other processes dont see /n/foo. I fork a child and it gets /n/foo, too. In the child I mount another directory and the changes are seen in both the child and the parent. I then echo copyns to /n/ctl and then perform another mount and the new mount is visible in the child process but not the parent process. This would of course require that the kernel filesystem (probably vfs layer) could distinguish who made a filesystem request. It might also require some hackery to get the inheritance on fork working properly (although perhaps some existing unix mechanism could be reused for this purpose, such as session and process group stuff). Feasible at all in Linux? *BSD? Win32? Upsides: Kernel doesnt need to otherwise support any notion of mount namespace. Removes security concerns of per-process namespaces since you could never rebind over /etc/passwd or other important files. Downsides: Perhaps not possible. Mount/bind namespaces not universally present, only within certain mount points. ron Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergeneri...@gmail.com wrote: On Mon, Jul 13, 2009 at 6:41 PM, J.R. Maurojrm8...@gmail.com wrote: On Mon, Jul 13, 2009 at 7:16 PM, ron minnichrminn...@gmail.com wrote: On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote: We hope to. One of the reasons it would actually be unwise to let anyone mount anything now is that no one uses per-process namespaces. That's probably fine on your desktop, but not on a server where 20 people try to mount something under /mnt/foo or whatnot. Could we solve this by making private mounts the default (or only allowed) behavior? It would be nice to fix up mounts so that you didn't need to be root and all that crap, and then make it the default, but I doubt Linus would let it fly. I get the feeling that private namespaces are viewed like chroots: a security feature no one but pros needs. Unfortunately not many linux devs seem to care about plan 9, and that has a negative impact on how much stuff can happen. Hopefully we'll gradually wear them down, or keep a minifork/patchset. When things get further along we can do a coordinated assault :) Indeed :) We've got bits of mindshare spread out over different places including a couple of the major distributions, if things can be made optional We've got Greg KH and Christoph on our side. I'm sure viro would also be a voice in our favor, and he has some pull with Linus they'll make it into mainline and then we just need to focus on education by presenting demos at places like OLS, Plumbers, and LCA -- and maybe get some good video podcast tutorials up on YouTube to get people wanting and using the features. Of course the main thing is finding a niche that needs the features and selling them on it. The focus on cloud computing and other cluster type solutions in mainstream computing may be helpful there. Yes, showing people the benefits of /net and how simple clustering is will be the path to victory. People will be amazed when they see how easy it is to make 5 computers pretend to be one. -eric
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 8:08 PM, ron minnichrminn...@gmail.com wrote: you need to find the niche and provide programs, which people can just use. Or you need to find the niche that lets other people write programs, and we're not where we need to be on that score. It's still too hard for people to write servers and there's no clear answer on which library to use. FUSE has done a great job in this area. ron Unfortunately, the only niches being filled are by other 9fans :P We've got some cool stuff by sqweek and Kris Maglione that are linux-specific, but the world at large is mostly ignorant of it. I'm sure adding things like /net will turn the tide.
Re: [9fans] v9fs question
On Mon Jul 13 20:43:21 EDT 2009, news...@lava.net wrote: Could we solve this by making private mounts the default (or only allowed) behavior? I've wondered if there's enough context information that the fs driver could fake per-process mount points directly. For example, I mount v9fs on /n. Initially I have no remote mounts in there, but I have /n/ctl. I echo mount 1.2.3.4 foo to /n/ctl and now I have /n/foo which is served from 1.2.3.4 for my process, but other processes dont see /n/foo. I fork a child and it gets /n/foo, too. In the child I mount another directory and the changes are seen in both the child and the parent. I then echo copyns to /n/ctl and then perform another mount and the new mount is visible in the child process but not the parent process. i believe you've described the speaks-for relationship in plan 9. This would of course require that the [linux] kernel filesystem (probably vfs layer) could distinguish who made a filesystem request. It might also require some hackery to get the inheritance on fork working properly (although perhaps some existing unix mechanism could be reused for this purpose, such as session and process group stuff). how could the fs record the creat without having the uid/gid? - erik
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 7:42 PM, Tim Newshamnews...@lava.net wrote: Could we solve this by making private mounts the default (or only allowed) behavior? I've wondered if there's enough context information that the fs driver could fake per-process mount points directly. Lucho's v9fs auth mechanisms allow for per-user namespaces (sort-of) as they force a new-attach ever time a new user crosses the mount point. I think there's enough knowledge (in Linux anyways) to obtain the current process. The hard bit is, as you say, managing inheritance and other namespace process controls. This is why its probably best implemented in a more integrated fashion. I have been playing with using Inferno to construct dynamic namespaces for me in Linux and MacOSX. The idea is to setup the namespace and then back mount it (with v9fs and FUSE) in either a private namespace or a chroot. I'm using this to implement an xcpu2-like environment purely with Inferno (remote threads get their own private namespace sandboxes to run in with an Inferno crafted namespace). Not as powerful as the whole enchilada, but it provides a container environment with composable namespaces. -eric
Re: [9fans] v9fs question
On Mon, Jul 13, 2009 at 7:42 PM, J.R. Maurojrm8...@gmail.com wrote: On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergeneri...@gmail.com wrote: On Mon, Jul 13, 2009 at 6:41 PM, J.R. Maurojrm8...@gmail.com wrote: On Mon, Jul 13, 2009 at 7:16 PM, ron minnichrminn...@gmail.com wrote: On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote: they'll make it into mainline and then we just need to focus on education by presenting demos at places like OLS, Plumbers, and LCA -- and maybe get some good video podcast tutorials up on YouTube to get people wanting and using the features. Of course the main thing is finding a niche that needs the features and selling them on it. The focus on cloud computing and other cluster type solutions in mainstream computing may be helpful there. Yes, showing people the benefits of /net and how simple clustering is will be the path to victory. People will be amazed when they see how easy it is to make 5 computers pretend to be one. I can validate this to some extent. The ability to transitively mount /net was one of the most popular features of the Library OS environment I worked on a few years back. It was really easy for Linux and UNIX minded folks to grasp how powerful it was: http://portal.acm.org/citation.cfm?id=1254810.1254817 -eric
Re: [9fans] v9fs question
I believe Priyanka has some significant work on getting private per-process namespaces in Glendix for this year's GSoC. --dho
Re: [9fans] v9fs question
I don't see why should we do tricks like that. We have support for private namespaces, why should we make the linux code even more complicated? Some of us use systems other than Linux. Also, it may be easier to sell one idea (v9fs) than two ideas (v9fs + private name spaces). It seems that people who have used UNIX for a long time have a natural aversion to the latter. Thanks, Lucho Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] v9fs question
I have a variant using Inferno right now, mounting the file system directly from the stdin/stdout of the emu. This isn't very practical in my case, because I need to port emu to the Yeeloong first. Hiro suggested using v9fs+ssh, I'd be interested in that option as a stopgap, but again some directions would be helpful. ++L
Re: [9fans] v9fs question
On the security side, I helped get the plan9-style authentication device in the mainline kernel. It's in staging. I guess the PAM module is 90% done, but they need some help if anyone is interested. Where do I look for this? I don't know Linux or PAM well enough to believe I can help, but one never knows. ++L
Re: [9fans] v9fs question
I've wondered if there's enough context information that the fs driver could fake per-process mount points directly. A totally uneducated shot in the dark: would having a userspace mount command that creates a private namespace (vaguely what you describe in your note) not be a good starting point? I'd use /ns rather than /n as the root, but that's really a small thing. Unfortunately, I have no idea (yet) of the machinery provided by Linux to construct private namespaces. And I am not aware of any equivalent work in the NetBSD world. ++L
Re: [9fans] v9fs question
On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
Hmmm, that's really new behavior-- never used to fail without mount helper.
Can you give the exact error message?
# strace -o trace.txt mount -t 9p thenewsh.com /mnt
mount: Protocol not supported
Trace.txt is attached with full details.
I've tried several variants, such as thenewsh.com:/path
with similar results.
On Jul 11, 2009, at 1:46 PM, Tim Newsham news...@lava.net wrote:
The documentation in the linux kernel says you merely
mount -t 9p ipaddress /mntpoint
this fails on my system since /sbin/mount tries to execute /sbin/mount.9p
and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which
ubunutu package should have this? If not, where I might find sources?
Ironic since Ubuntu came with the 9p kernel module) Or should I be using a
different mount program for the purpose?
The linux Documentation/filesystems/9p.txt should probably be updated with
more details, either way.
Tim Newsham
http://www.thenewsh.com/~newsham/
Tim Newsham
http://www.thenewsh.com/~newsham/execve(/bin/mount, [mount, -t, 9p, thenewsh.com, /mnt], [/* 39 vars
*/]) = 0
brk(0) = 0x805e000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7faf000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=53546, ...}) = 0
mmap2(NULL, 53546, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa1000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libselinux.so.1, O_RDONLY) = 3
read(3, \177elf\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\...@\0..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=95948, ...}) = 0
mmap2(NULL, 101180, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7f88000
mmap2(0xb7f9f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16) = 0xb7f9f000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1364388, ...}) = 0
mmap2(NULL, 1369712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e39000
mmap2(0xb7f82000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149) = 0xb7f82000
mmap2(0xb7f85000, 9840, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f85000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libdl.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9684, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e38000
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e34000
mmap2(0xb7e36000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7e36000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e33000
set_thread_area({entry_number:-1 - 6, base_addr:0xb7e33720, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb7f82000, 4096, PROT_READ) = 0
munmap(0xb7fa1000, 53546) = 0
brk(0) = 0x805e000
brk(0x807f000) = 0x807f000
open(/etc/selinux/config, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
statfs64(/selinux, 84, 0xbfea3dfc)= -1 ENOENT (No such file or directory)
open(/proc/mounts, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fae000
read(3, rootfs / rootfs rw 0 0\nnone /sys..., 1024) = 1024
read(3, p_id=1000 0 0\n, 1024)= 14
read(3, , 1024) = 0
close(3)= 0
munmap(0xb7fae000, 4096)= 0
open(/usr/lib/locale/locale-archive, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/share/locale/locale.alias, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2586, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fae000
read(3, # Locale name alias data base.\n#..., 4096) = 2586
read(3, , 4096) = 0
close(3)= 0
munmap(0xb7fae000, 4096)= 0
open(/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION, O_RDONLY) = -1 ENOENT (No
such file or directory)
Re: [9fans] v9fs question
Try an ip address instead of the DNS name. For the DNS name you'll need a helper like 9mount. Sent from my iPhone On Jul 11, 2009, at 2:03 PM, Tim Newsham news...@lava.net wrote: On Sat, 11 Jul 2009, Eric Van Hensbergen wrote: Hmmm, that's really new behavior-- never used to fail without mount helper. Can you give the exact error message? # strace -o trace.txt mount -t 9p thenewsh.com /mnt mount: Protocol not supported Trace.txt is attached with full details. I've tried several variants, such as thenewsh.com:/path with similar results. On Jul 11, 2009, at 1:46 PM, Tim Newsham news...@lava.net wrote: The documentation in the linux kernel says you merely mount -t 9p ipaddress /mntpoint this fails on my system since /sbin/mount tries to execute /sbin/ mount.9p and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which ubunutu package should have this? If not, where I might find sources? Ironic since Ubuntu came with the 9p kernel module) Or should I be using a different mount program for the purpose? The linux Documentation/filesystems/9p.txt should probably be updated with more details, either way. Tim Newsham http://www.thenewsh.com/~newsham/ Tim Newsham http://www.thenewsh.com/~newsham/ trace.txt
Re: [9fans] v9fs question
On Sat, Jul 11, 2009 at 3:03 PM, Tim Newshamnews...@lava.net wrote: On Sat, 11 Jul 2009, Eric Van Hensbergen wrote: Hmmm, that's really new behavior-- never used to fail without mount helper. Can you give the exact error message? # strace -o trace.txt mount -t 9p thenewsh.com /mnt Linux doesn't do resolution for you, you have to give raw ip addresses. Maybe not the problem, but worth pointing out. mount: Protocol not supported Trace.txt is attached with full details. I've tried several variants, such as thenewsh.com:/path with similar results. On Jul 11, 2009, at 1:46 PM, Tim Newsham news...@lava.net wrote: The documentation in the linux kernel says you merely mount -t 9p ipaddress /mntpoint this fails on my system since /sbin/mount tries to execute /sbin/mount.9p and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which ubunutu package should have this? If not, where I might find sources? Ironic since Ubuntu came with the 9p kernel module) Or should I be using a different mount program for the purpose? The linux Documentation/filesystems/9p.txt should probably be updated with more details, either way. Tim Newsham http://www.thenewsh.com/~newsham/ Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] v9fs question
Using sqweek's 9mount is strongly recommended if you are using v9fs, not only it deals with the silly and deficient linux mount command (which somebody should submit a patch for some day I guess if we want to be taken seriously as an nfs replacement), but it also hides the ever changing v9fs mount flags under a more consistent and clear interface. The ability to mount and unmount 9p file servers without being root is just a great extra. http://sqweek.dnsdojo.org/code/9mount/ uriel P.S.: Oh, and I think debian even packages 9mount! On Sat, Jul 11, 2009 at 10:03 PM, J.R. Maurojrm8...@gmail.com wrote: On Sat, Jul 11, 2009 at 3:03 PM, Tim Newshamnews...@lava.net wrote: On Sat, 11 Jul 2009, Eric Van Hensbergen wrote: Hmmm, that's really new behavior-- never used to fail without mount helper. Can you give the exact error message? # strace -o trace.txt mount -t 9p thenewsh.com /mnt Linux doesn't do resolution for you, you have to give raw ip addresses. Maybe not the problem, but worth pointing out. mount: Protocol not supported Trace.txt is attached with full details. I've tried several variants, such as thenewsh.com:/path with similar results. On Jul 11, 2009, at 1:46 PM, Tim Newsham news...@lava.net wrote: The documentation in the linux kernel says you merely mount -t 9p ipaddress /mntpoint this fails on my system since /sbin/mount tries to execute /sbin/mount.9p and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which ubunutu package should have this? If not, where I might find sources? Ironic since Ubuntu came with the 9p kernel module) Or should I be using a different mount program for the purpose? The linux Documentation/filesystems/9p.txt should probably be updated with more details, either way. Tim Newsham http://www.thenewsh.com/~newsham/ Tim Newsham http://www.thenewsh.com/~newsham/
