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
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.
(Even
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 with the
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
On Sat, Jan 3, 2009 at 1:33 PM, Roman V. Shaposhnik r...@sun.com 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
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
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 specially crafted
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 r...@sun.com 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
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[0] =
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,
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:
case
Isn't it too restrictive, eg, not allowing you to create pipes?
On Sat, Jan 3, 2009 at 11:40 PM, Roman V. Shaposhnik r...@sun.com 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
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 =
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
with
On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom quans...@quanstro.net 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
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
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
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 to
On Sat, 2009-01-03 at 15:15 -0800, Russ Cox wrote:
On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom quans...@quanstro.net 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
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
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 hardware
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 would you
'#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
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 opposed
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 tested in
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 not tested in
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 to
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 case.
On Sat, Jan 3, 2009 at 9:04 PM, Roman V. Shaposhnik r...@sun.com 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
On Sat, Jan 3, 2009 at 9:12 PM, Roman V. Shaposhnik r...@sun.com 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
38 matches
Mail list logo
