Re: [9fans] bug in exportfs

[Bruce Ellis]

an alternative is just to have an exclude file listing files/directories
that cannot be read or walked to.

brucee

On 15 February 2016 at 12:05, arisawa  wrote:

> Hello,
>
> > 2016/02/15 7:57、Charles Forsyth  のメール：
> >
> >
> > On 14 February 2016 at 16:38,  wrote:
> > i could imagine the filtering being usefull when cpu'ing to foreign
> machines,
> > as a server can easily compromize your system when cpu exports your whole
> > local namespace
> >
> > You'd still be better off using a custom nsfile to control it, running
> that cpu in
> > a more restricted name space from the start, so leaks are impossible.
>
> filtering of exportfs is handy if it works well.
> for example, assume we want to exclude all files of name that begins with
> “.”,
> then it is probably difficult to do so using only nsfile.
>
> the “+” filtering is almost useless.
> it will not be difficult to rewrite the current code so that we have
> better matching rule.
> (I think ordering of pattern sequence should be used in evaluation.)
> however the change may break something others.
> (but I doubt the “+” filtering is really used)
>
>
>
>

Re: [9fans] bug in exportfs

[arisawa]

Hello,

> 2016/02/15 7:57、Charles Forsyth  のメール：
> 
> 
> On 14 February 2016 at 16:38,  wrote:
> i could imagine the filtering being usefull when cpu'ing to foreign machines,
> as a server can easily compromize your system when cpu exports your whole
> local namespace
> 
> You'd still be better off using a custom nsfile to control it, running that 
> cpu in
> a more restricted name space from the start, so leaks are impossible.

filtering of exportfs is handy if it works well.
for example, assume we want to exclude all files of name that begins with “.”,
then it is probably difficult to do so using only nsfile.

the “+” filtering is almost useless.
it will not be difficult to rewrite the current code so that we have better 
matching rule.
(I think ordering of pattern sequence should be used in evaluation.)
however the change may break something others.
(but I doubt the “+” filtering is really used)

Re: [9fans] bug in exportfs

[Charles Forsyth]

On 14 February 2016 at 16:38,  wrote:

> i could imagine the filtering being usefull when cpu'ing to foreign
> machines,
> as a server can easily compromize your system when cpu exports your whole
> local namespace
>

You'd still be better off using a custom nsfile to control it, running that
cpu in
a more restricted name space from the start, so leaks are impossible.

Re: [9fans] bug in exportfs

[Charles Forsyth]

On 13 February 2016 at 14:26, Charles Forsyth 
wrote:

> I really wonder about the pattern-matching code being there at all.


One interesting thing about the implementation is that it goes so far as to
edit the result of directory reads,
so excluded names can't be seen in ls.

Re: [9fans] bug in exportfs

[Charles Forsyth]

On 14 February 2016 at 10:27, hiro <23h...@gmail.com> wrote:

> You mean this?


No, there was a handful of Plan 9 patents, mainly to do with aspects and
applications of computable name spaces and related services.

[9fans] plan9.ini: ipconfig and bootargs

[tlaronde]

Hello,

When trying to re-install a Plan9 on a new node, being unable, with the
kernel compiled present on the CDROM image, to access a FAT or an iso
image of a root file system, I went to a combination of a minimal sketch
of a plan9 slice, with a 9fat made "by hand" (from an already installed
other OS---here NetBSD) and access at boot time a remote root
filesystem, for the installation, serves by another Unix node serving
9P2000.

The surprise is with the bootargs, in plan9.ini, supposed to configure
the network for the node, in order to access a remote root filesystem,
as in:

fs=192.168.1.3
# auth not used
auth=192.168.1.3
bootargs=tcp!-g 192.168.1.1 gbe 192.168.1.2 255.255.255.0

what is after the '!' being supposed to be args to ip/ipconfig.

The problem is that the gateway is taken as _another_ ip address for the
interface! and that the mask is taken as the "node" serving the root
filesystem! "fs" not being taken into account.

Only:

bootargs=tcp!gbe 192.168.1.2

works...

Is the ip/ipconfig embedded in boot reduced as to not take all the
options? (I don't need them; but the wiki page is the wrong; and
I wonder if I'm doing something wrong or if there is indeed something
changed since the page was written...)

-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] bug in exportfs

[cinap_lenrek]

i could imagine the filtering being usefull when cpu'ing to foreign machines,
as a server can easily compromize your system when cpu exports your whole
local namespace. i dont know if anyone has done this tho.

--
cinap

Re: [9fans] bug in exportfs

[hiro]

You mean this?
http://inventors.about.com/od/tstartinventions/ss/TelephonePatent.htm

On 2/14/16, Prof Brucee  wrote:
> Totally agree. I've never needed exportfs filtering. It's not in the
> patent.
> On 14/02/2016 1:27 AM, "Charles Forsyth"  wrote:
>
>>
>> On 22 December 2015 at 10:02, arisawa  wrote:
>>
>>>
>>> The difficulty is in the pattern matching rule.
>>> If we want to export only /usr/glenda, then the pattern matching filer
>>> must pass
>>> /usr
>>> /usr/glenda
>>> and must not pass
>>> /usr/
>>>
>>
>> I really wonder about the pattern-matching code being there at all.
>> Without it, exportfs is constrained by the authenticated user's
>> permissions, within the exported name space,
>> and that's enforced by the operating system (system calls).
>> To export only /usr/glenda, I'd build a name space that has only
>> /usr/glenda in it, and export that.
>>
>> The read-only option is enforced by exportfs itself, but at the 9P level:
>> it's not too hard to enumerate
>> the messages and options that do not cause modifications and reject all
>> others (although exportfs wasn't updated to include an
>> option added later to open). Still, that can be got right once for all by
>> exportfs.
>>
>