2009/7/14 Tim Newsham :
> 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.
On Tue, Jul 14, 2009 at 2:05 PM, sqweek 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
2009/7/13 Eric Van Hensbergen :
> On Mon, Jul 13, 2009 at 3:24 AM, sqweek 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 direct
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
comman
> > 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
On Tue, Jul 14, 2009 at 11:12 AM, erik quanstrom 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
On Tue, Jul 14, 2009 at 10:48 AM, ron minnich wrote:
> On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkov 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 no
On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkov 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 lo
On Tue, Jul 14, 2009 at 4:08 AM, roger peppe 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, authenticatio
On Tue, Jul 14, 2009 at 10:19 AM, erik quanstrom 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 im
> > 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 t
On Tue, Jul 14, 2009 at 10:01 AM, erik quanstrom 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 w
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 Hensbergen wrote:
> I thought at one point in time we
> 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?
On Tue, Jul 14, 2009 at 9:33 AM, Latchesar Ionkov 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) vers
> Is something not working?
authentication? or doesn't that count?
- erik
On Tue, Jul 14, 2009 at 1:34 AM, sqweek 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
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, sqweek wrote:
> 2009/7/13 Latchesar Ionkov :
>> On Mon, Jul 13, 2009 at 2:2
On Tue, Jul 14, 2009 at 8:23 AM, erik quanstrom 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 elsew
> 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 addi
On Jul 14, 2009, at 2:34 AM, sqweek wrote:
2009/7/13 Latchesar Ionkov :
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
On Jul 14, 2009, at 6:08 AM, roger peppe 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
(li
On Tue, Jul 14, 2009 at 1:08 PM, roger peppe 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 des
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
2009/7/13 Latchesar Ionkov :
> On Mon, Jul 13, 2009 at 2:24 AM, sqweek 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
> 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 start
> 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 o
> 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
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 peo
I believe Priyanka has some significant work on getting private
per-process namespaces in Glendix for this year's GSoC.
--dho
On Mon, Jul 13, 2009 at 7:42 PM, J.R. Mauro wrote:
> On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergen wrote:
>> On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro wrote:
>>> On Mon, Jul 13, 2009 at 7:16 PM, ron minnich wrote:
On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro wrote:
>> they'll make it i
On Mon, Jul 13, 2009 at 7:42 PM, Tim Newsham 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 mechanis
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
On Mon, Jul 13, 2009 at 8:08 PM, ron minnich 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 serve
On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergen wrote:
> On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro wrote:
>> On Mon, Jul 13, 2009 at 7:16 PM, ron minnich wrote:
>>> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro wrote:
>>>
We hope to. One of the reasons it would actually be unwise to let
>
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
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
> > (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
On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro wrote:
> On Mon, Jul 13, 2009 at 7:16 PM, ron minnich wrote:
>> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro 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 names
On Mon, Jul 13, 2009 at 7:50 PM, erik quanstrom 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
> 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 lin
On Mon, Jul 13, 2009 at 6:37 PM, ron minnich wrote:
> On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergen 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.
>
> W
On Mon, Jul 13, 2009 at 7:16 PM, ron minnich wrote:
> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro 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 o
On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergen 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
On Mon, Jul 13, 2009 at 6:16 PM, ron minnich wrote:
> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro 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 o
On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro 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
On Mon, Jul 13, 2009 at 6:05 PM, Eric Van Hensbergen wrote:
> On Mon, Jul 13, 2009 at 4:45 PM, hiro<23h...@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 li
On Mon, Jul 13, 2009 at 4:45 PM, hiro<23h...@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
On Mon, Jul 13, 2009 at 3:44 PM, hiro<23h...@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 a
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
> 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
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
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, wrote:
>> Anyway, note that if you auth you'll need supporting software from
>> p9p also. Factotum and srv -a, in particular,
On Mon, Jul 13, 2009 at 2:24 AM, sqweek 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
> 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,
On Mon, Jul 13, 2009 at 3:24 AM, sqweek 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 avail
> mount: Protocol not supported
There was a time where you had to modprobe 9p2000 first. Should be worth a try.
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 yo
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
On Sat, Jul 11, 2009 at 3:03 PM, Tim Newsham 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
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 wrote:
On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
Hmmm, that's really new behavior-- never used to fail without mount
helper. Ca
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
Hmmm, that's really new behavior-- never used to fail without mount
helper. Can you give the exact error message?
Patches to documentation and/or code gladly accepted.
Sent from my iPhone
On Jul 11, 2009, at 1:46 PM, Tim Newsham wrote:
The documentation in the linux kernel says you mere
63 matches
Mail list logo
