On Wed, 2009-01-07 at 01:24 -0500, Dave Eckhardt wrote:
RFNOMNT, like everything in Plan 9, was put in because
someone needed to use it, not as a purely academic
exercise in adding features.
Here is something which either I've misunderstood or is
harder than I'd like.
[...]
What does
On Thu, Jan 08, 2009 at 07:57:42PM +, Charles Forsyth wrote:
It now seems, that if your process has a read/write access to
a channel capable of speaking 9P not letting it mount that
channel really doesn't accomplish much: whatever messages kernel
would send on your behalf, you can send
It now seems, that if your process has a read/write access to
a channel capable of speaking 9P not letting it mount that
channel really doesn't accomplish much: whatever messages kernel
would send on your behalf, you can send directly.
note that if a Chan has once been mounted it can no longer
i was just pointing it out: i wasn't suggesting that it
necessarily added security. (it was a response to the remark
that a process could send arbitrary messages; not necessarily.)
having said that, i'm not sure it's really a race, more of an ordering
restriction:
if you mount it before posting,
On Thu, 2009-01-08 at 19:57 +, Charles Forsyth wrote:
It now seems, that if your process has a read/write access to
a channel capable of speaking 9P not letting it mount that
channel really doesn't accomplish much: whatever messages kernel
would send on your behalf, you can send
On Wed, Jan 7, 2009 at 3:24 PM, Dave Eckhardt davide...@cs.cmu.edu wrote:
The web server infrastructure seems pretty focused on running
as user none, which makes sense as far as it goes, but I
don't want none to be able to read the files served by the
web servers because anybody who can log in
RFNOMNT, like everything in Plan 9, was put in because
someone needed to use it, not as a purely academic
exercise in adding features.
Here is something which either I've misunderstood or is
harder than I'd like.
I have a machine which runs two private (password-protected)
web servers on
The let's submit a patch and fix it talk is scary.
i haven't seen any such talk; and in any event,
how can patches be scary?
All the pie-in-the-sky gee it would be nice if it worked
like this, not that I'm actually using it talk is unproductive.
if it helps understand what's there, why it's
I agree that it would be nice if the exceptions were
documented in the man page. They are quite nicely
documented in the code, though:
/*
* noattach is sandboxing.
*
* the OK exceptions are:
* | it only
It's behavior is what it is
because that was necessary to get the job done.
This approach can lead to unexpected side effects. Roman (or was it
Nathaniel?) shows how RFNOMNT may be misunderstood to perform two
functions when in fact there is only one purpose to it. In addition,
only the
I agree that it would be nice if the exceptions were
documented in the man page. They are quite nicely
documented in the code, though:
That's easy enough to do, I'm sure. I'll look into that and see if I
can build the confidence for a patch to, I presume, rfork(2)?
The rationale is also at
On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote:
The let's submit a patch and fix it talk is scary.
Russ, with all due respect, life gets unnecessarily complicated
when on one hand whenever I suggest something for discussion
there's always a member of this list (you included) who asks
me to
i understood what Russ said to mean: patches -- for enhancements that
might someday have a use or fixes that remove some perceived
shortcoming lacking an actual need -- are scary.
On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote:
The let's submit a patch and fix it talk is scary.
Russ, with
i understood what Russ said to mean: patches -- for enhancements that
might someday have a use or fixes that remove some perceived
shortcoming lacking an actual need -- are scary.
Not if they are first discussed in the type of forum that is savvy to
both the immediate effects and the hidden
I apologize for the tone of my first message.
Skip put the words better in his rephrasing.
I was speaking only for myself -- I have no part
in applying patches to Plan 9 anymore. I submit
changes the same as everyone else.
I would hope that any patch changing the behavior
of RFNOMNT would be
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
16 matches
Mail list logo
