>> snarf doesnt work properly in plan9 on vmware fusion 2.0 for mac. from what
>> i found this seems to be a known issue. is there any fix available?
>
> no; someone needs to write a new version
> of the vmware tools that works with the latest
> vmware versions.
>
> russ
i've been reviewing open
> i've been reviewing open-vm-tools[1] and Russ' vmwarefs. from what i
> can tell the old backdoor (low bandwidth) mechanism is still supported
> and the protocol hasn't changed. there's an alternative high
> bandwidth mechanism but i'm not sure if the advent of the high
> bandwidth rpc was later
[ I took a liberty to merge two of your emails together for the ease of
commenting ]
On Thu, 2009-01-01 at 18:57 -0500, Nathaniel W Filardo wrote:
> That is, the claim that "a process spawned without access to your home
> directory cannot get it" is flawed if that process runs as your user.
> (Ev
On Sat, 2009-01-03 at 10:21 -0800, Skip Tavakkolian wrote:
> >> snarf doesnt work properly in plan9 on vmware fusion 2.0 for mac. from what
> >> i found this seems to be a known issue. is there any fix available?
> >
> > no; someone needs to write a new version
> > of the vmware tools that works w
Guys,
while replying to Nathaniel's post it dawned on
me that something like this:
open("#c/cons", OWRITE|OCEXEC);
completely breaks the paradigm of namespaces.
IOW, if I wanted to construct a namespace with
a specially crafted server offering /dev/cons,
the above would easily break out of th
On Sat, Jan 3, 2009 at 1:33 PM, Roman V. Shaposhnik wrote:
> Where's the source code for vmwarefs located?
http://9fans.net/archive/2008/12/180
Russ
>1. Virtualizing root account, so that every Zone can have its own
>2. Virtualizing the global UNIX namespace
>3. Virtualizing TCP/IP stack
>4. Virtualizing drivers providing access to the service provided
> by the kernel itself (things like /proc, etc.)
>5. Implementing p
> while replying to Nathaniel's post it dawned on
> me that something like this:
> open("#c/cons", OWRITE|OCEXEC);
> completely breaks the paradigm of namespaces.
>
> IOW, if I wanted to construct a namespace with
> a specially crafted server offering /dev/cons,
> the above would easily break
On Sat, 2009-01-03 at 16:46 -0500, erik quanstrom wrote:
> > while replying to Nathaniel's post it dawned on
> > me that something like this:
> > open("#c/cons", OWRITE|OCEXEC);
> > completely breaks the paradigm of namespaces.
> >
> > IOW, if I wanted to construct a namespace with
> > a speci
On Sat, 2009-01-03 at 16:41 -0500, erik quanstrom wrote:
> there's also nothing preventing one from implementing a
> filtering fs that restricts the directories available in /proc.
True. But there are two problems with a filtering fs:
1. Accessing #p would bypass the fs 100%
2. For things like
On Tue, Dec 30, 2008 at 8:54 AM, Roman Shaposhnik wrote:
> Personally, though, I'd say that the usefulness of the
> dump would be greatly improved
> if one had an ability to do ad-hoc archival snapshots AND assigning tags,
> not only dates to them.
Tags don't make that much sense in this context
> Did you see the example I provided in the original
> email? "rfork m" is *exactly* RFNOMNT. And it doesn't
> seem to work for one simple reason: RFNOMNT doesn't
> restrict bind(2).
these are exceptions. from port/chan.c:
case '#':
nomount = 1;
up->genbuf
Usign #X means doing a mount (you are attaching to the root
of the driver's tree).
However, for, drivers with letters |decp
you can always attach to them no matter if RFNOMNT was
used.
Probably it was considered too restrictive not doing so, but that's IMHO.
On Sat, Jan 3, 2009 at 10:56 PM, Roma
On Sat, 2009-01-03 at 17:03 -0500, erik quanstrom wrote:
> > Did you see the example I provided in the original
> > email? "rfork m" is *exactly* RFNOMNT. And it doesn't
> > seem to work for one simple reason: RFNOMNT doesn't
> > restrict bind(2).
>
> these are exceptions. from port/chan.c:
>
>
Isn't it too restrictive, eg, not allowing you to create pipes?
On Sat, Jan 3, 2009 at 11:40 PM, Roman V. Shaposhnik wrote:
> On Sat, 2009-01-03 at 17:03 -0500, erik quanstrom wrote:
>> > Did you see the example I provided in the original
>> > email? "rfork m" is *exactly* RFNOMNT. And it doesn'
> Probably it was considered too restrictive not doing so, but that's IMHO.
there are suprisingly few uses of this. even nsec opens /dev/bintime
directly. none seem particularly compelling.
minooka; grep -n open `{find lib*|grep '\.[ch]$'}|grep '"#[|decp]'
libc/9sys/getpid.c:11: f = open("#c/p
> Isn't it too restrictive, eg, not allowing you to create pipes?
pipes certianly are an exception. why can the others
be bound for you if your jailer sees fit?
- erik
> And finally, I'd say having these exceptions is a mistake. Unless,
> there's a really good reason, they break the paradigm of RFNOMNT
> quite needlessly without even a hint of a benefit.
so, it's likely that RFNOMNT was added and to avoid
breaking too many things, a few exceptions were added
wit
On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom wrote:
>> And finally, I'd say having these exceptions is a mistake. Unless,
>> there's a really good reason, they break the paradigm of RFNOMNT
>> quite needlessly without even a hint of a benefit.
>
> so, it's likely that RFNOMNT was added and to av
>>> And finally, I'd say having these exceptions is a mistake. Unless,
>>> there's a really good reason, they break the paradigm of RFNOMNT
>>> quite needlessly without even a hint of a benefit.
>>
>> so, it's likely that RFNOMNT was added and to avoid
>> breaking too many things, a few exceptions
On Sat, Jan 03, 2009 at 01:23:02PM -0800, Roman V. Shaposhnik wrote:
> [ I took a liberty to merge two of your emails together for the ease of
> commenting ]
Thanks. :)
> On Thu, 2009-01-01 at 18:57 -0500, Nathaniel W Filardo wrote:
> > That is, the claim that "a process spawned without access
On Sat, 2009-01-03 at 17:56 -0500, erik quanstrom wrote:
> > Isn't it too restrictive, eg, not allowing you to create pipes?
>
> pipes certianly are an exception. why can the others
> be bound for you if your jailer sees fit?
Why would you call pipes an exception? Is there anything special
about
On Sat, 2009-01-03 at 23:46 +0100, Francisco J Ballesteros wrote:
> Isn't it too restrictive, eg, not allowing you to create pipes?
It depends. The point, however, is that NOT allowing to restrict
*all* attaches seem far more restrictive. ;-)
Besides, my main concern is not about restricting at a
I'm confused. Is there any part of syspipe() that can NOT
be done from userspace? Why does it have to be a syscall?
Thanks,
Roman.
P.S. I would also argue that sysdup() would seem to be superfluous
if more feature-rich devdup was available.
On Sat, 2009-01-03 at 17:57 -0500, erik quanstrom wrote:
> > And finally, I'd say having these exceptions is a mistake. Unless,
> > there's a really good reason, they break the paradigm of RFNOMNT
> > quite needlessly without even a hint of a benefit.
>
> so, it's likely that RFNOMNT was added and
On Sat, 2009-01-03 at 15:15 -0800, Russ Cox wrote:
> On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom wrote:
> >> And finally, I'd say having these exceptions is a mistake. Unless,
> >> there's a really good reason, they break the paradigm of RFNOMNT
> >> quite needlessly without even a hint of a be
On Sat, 2009-01-03 at 23:21 +0100, Francisco J Ballesteros wrote:
> Usign #X means doing a mount (you are attaching to the root
> of the driver's tree).
You're right, of course. But it feels like a very special mount
if one can refer to files served by the drivers directly through:
'#X/bla-bla'.
> '#p'
> allows any of my namespaces to debug processess in any other, '#s' is too
> global, and /net seems to allow any of my processes to manipulate any of my
> other processes' network connections (though I've not tested in detail to
> see what's possible.)
So you're saying that (a) a jailed pr
> > Usign #X means doing a mount (you are attaching to the root
> > of the driver's tree).
>
> You're right, of course. But it feels like a very special mount
> if one can refer to files served by the drivers directly through:
> '#X/bla-bla'.
s/driver/file server/
there doesn't need to be any har
> could you explain why you think this is special?
Perhaps because it is _always_ part of the namespace, where this
discussion is specifically about restricting the namespace? Of
course, that is how I read it, Roman will need to qualify my view.
++L
PS: I also find #X a touch special, but there
On Sun Jan 4 00:01:18 EST 2009, r...@sun.com wrote:
> On Sat, 2009-01-03 at 17:56 -0500, erik quanstrom wrote:
> > > Isn't it too restrictive, eg, not allowing you to create pipes?
> >
> > pipes certianly are an exception. why can the others
> > be bound for you if your jailer sees fit?
>
> Why
> > '#p'
> > allows any of my namespaces to debug processess in any other, '#s' is too
> > global, and /net seems to allow any of my processes to manipulate any of my
> > other processes' network connections (though I've not tested in detail to
> > see what's possible.)
>
> So you're saying that (
> > could you explain why you think this is special?
>
> Perhaps because it is _always_ part of the namespace, where this
> discussion is specifically about restricting the namespace? Of
> course, that is how I read it, Roman will need to qualify my view.
the anticedent special was #X/fu as oppo
On Sun, Jan 04, 2009 at 07:19:35AM +0200, lu...@proxima.alt.za wrote:
> > '#p'
> > allows any of my namespaces to debug processess in any other, '#s' is too
> > global, and /net seems to allow any of my processes to manipulate any of my
> > other processes' network connections (though I've not test
On Sun, Jan 04, 2009 at 12:48:08AM -0500, erik quanstrom wrote:
> > > '#p'
> > > allows any of my namespaces to debug processess in any other, '#s' is too
> > > global, and /net seems to allow any of my processes to manipulate any of
> > > my
> > > other processes' network connections (though I've
>> Would that satisfy your requirements? Oh, sure, I haven't ever used
>> #| directly and I'm a bit ignorant of consequences, but the rest seems
>> feasible.
>
> I suspect #| being an exception wouldn't hurt, though it might be viewed as
> a historical wart, being the only one... could #| be made
> RFNOMNT has been brought up repeatedly and, while it's certainly better than
> nothing, it is too harsh! It simultaneously:
> -> restricts access to kernel devices via # paths
> -> prevents any and all additional mount requests.
>
Well, it does only the latter, the first is just a special c
On Sat, Jan 3, 2009 at 9:04 PM, Roman V. Shaposhnik wrote:
> I'm confused. Is there any part of syspipe() that can NOT
> be done from userspace? Why does it have to be a syscall?
>
> P.S. I would also argue that sysdup() would seem to be superfluous
> if more feature-rich devdup was available.
I
On Sat, Jan 3, 2009 at 9:12 PM, Roman V. Shaposhnik wrote:
> [complaint about # names]
No one has yet offered a working, cleaner idea.
Russ
RFNOMNT, like everything in Plan 9, was put in because
someone needed to use it, not as a purely academic
exercise in adding features. It's behavior is what it is
because that was necessary to get the job done.
All the pie-in-the-sky "gee it would be nice if it worked
like this, not that I'm actua
40 matches
Mail list logo
