Re: [9fans] bug in exportfs

[Charles Forsyth]

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

> filtering of exportfs is handy if it works well.
>
...

The whole short discussion was useful, thanks. It gave me a few ideas,
prompted by exportfs,
including about filtering.

Re: [9fans] bug in exportfs

[Charles Forsyth]

On 15 February 2016 at 15:30, erik quanstrom  wrote:

>
> sadly among its other sins, the plan 9 webserver does use .httplogin


but that's just an ordinary name; in fact, it's exactly that name that's
hidden, nothing to do with .:

httpd.c: * don't show the contents of .httplogin
httpd.c: if(strcmp(w+n-STRLEN(".httplogin"), ".httplogin") == 0)

Re: [9fans] bug in exportfs

[Skip Tavakkolian]

leading dot is a Jedi mind trick that only works on the weak minded. "these
aren't the files you' re looking for"


On Mon, Feb 15, 2016 at 7:38 AM erik quanstrom 
wrote:

> > My point was that under the circumstances we are stuck with people who
> > DO use the leading dot to make files disappear from directory listings
> > and they won't budge :-)
>
> what the intent of the leading dot might be is not recorded in the file
> system and
> one can ignore the convention as one wishes, with no impact to any other
> user.
> i don't remember the last time i've hidden dot files from myself by using
> only
> the standard options on a unix-y system.
>
> - erik
>
>

Re: [9fans] bug in exportfs

[erik quanstrom]

> My point was that under the circumstances we are stuck with people who
> DO use the leading dot to make files disappear from directory listings
> and they won't budge :-)

what the intent of the leading dot might be is not recorded in the file system 
and
one can ignore the convention as one wishes, with no impact to any other user.
i don't remember the last time i've hidden dot files from myself by using only
the standard options on a unix-y system.

- erik

Re: [9fans] bug in exportfs

[erik quanstrom]

> Yes, although that convention isn't in Plan 9, and it might be worthwhile
> reconsidering how and why it is used.
> If for configuration files, perhaps they should be stored elsewhere; if for
> access control (eg, .htaccess), perhaps
> groups would be better, with dynamic group membership providing the effect
> of an access control list.

sadly among its other sins, the plan 9 webserver does use .httplogin

- erik

Re: [9fans] bug in exportfs

[erik quanstrom]

On Mon Feb 15 07:08:06 PST 2016, lu...@proxima.alt.za wrote:
> > Ah, my memory fails me, mostly due to too much time on Unipress machines in 
> > the 1980's. 
> 
> Rob's explanation for how the hidden files came about is out there in the 
> wild.  I recall enjoying it. Probably one of Rob Pike's blog entries or 
> somesuch on his own web site.

https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

- erik

Re: [9fans] bug in exportfs

[lucio]

> Ah, my memory fails me, mostly due to too much time on Unipress machines in 
> the 1980's. 

Rob's explanation for how the hidden files came about is out there in the wild. 
 I recall enjoying it. Probably one of Rob Pike's blog entries or somesuch on 
his own web site.

Lucio.

Re: [9fans] bug in exportfs

[lucio]

> Not in Plan 9. They do not disappear from directory listings in Plan 9 (or
> even Plan 9 Port).
> There isn't even a -a option, because all names are listed.

I suppose you have a point in that exportfs is not likely to be used
outside of a Plan 9 environment, but that is a little parochial,
isn't it?

Lucio.

Re: [9fans] bug in exportfs

[Charles Forsyth]

On 15 February 2016 at 12:44,  wrote:

> My point was that under the circumstances we are stuck with people who
> DO use the leading dot to make files disappear from directory listings
> and they won't budge :-)
>

Not in Plan 9. They do not disappear from directory listings in Plan 9 (or
even Plan 9 Port).
There isn't even a -a option, because all names are listed.

Re: [9fans] bug in exportfs

[lucio]

> There is no "leading dot" convention in Plan 9.
> That's in BSD-derived UNIX, and it's the result of an simplified hack in
> ls, which was fixed in Seventh Edition.
> If you can open it, it's obviously not "hidden": it's just inconvenient to
> use with grep *.

I was hoping to put that issue to sleep, it is just one of many
idiocies that have caught the imagination of those who ultimately make
a difference.  Like including upper case in the alphabet.

My point was that under the circumstances we are stuck with people who
DO use the leading dot to make files disappear from directory listings
and they won't budge :-)

Lucio.

Re: [9fans] bug in exportfs

[Charles Forsyth]

On 15 February 2016 at 10:55,  wrote:

>
> Charles, I think Kenji has a point and you are diverting the
> discussion .
>

Not really: I'm trying to suggest possibilities for "what are you trying to
achieve" (by hiding dot files, say), and then
alternative mechanisms for that.

Re: [9fans] bug in exportfs

[Brantley Coile]

Ah, my memory fails me, mostly due to too much time on Unipress machines in the 
1980's. 

Sent from my iPad

> On Feb 15, 2016, at 7:08 AM, Charles Forsyth  
> wrote:
> 
> 
>> On 15 February 2016 at 10:55,  wrote:
>> 
>> Whereas I agree that the leading-dot convention ought to be buried, in
>> reality (a) it is not going to just go away and (b) if it was so
>> readily accepted, it must have fulfilled a need.
> 
> There is no "leading dot" convention in Plan 9.
> That's in BSD-derived UNIX, and it's the result of an simplified hack in ls, 
> which was fixed in Seventh Edition.
> If you can open it, it's obviously not "hidden": it's just inconvenient to 
> use with grep *.

Re: [9fans] bug in exportfs

[Charles Forsyth]

On 15 February 2016 at 10:55,  wrote:

>
> Whereas I agree that the leading-dot convention ought to be buried, in
> reality (a) it is not going to just go away and (b) if it was so
> readily accepted, it must have fulfilled a need.
>

There is no "leading dot" convention in Plan 9.
That's in BSD-derived UNIX, and it's the result of an simplified hack in
ls, which was fixed in Seventh Edition.
If you can open it, it's obviously not "hidden": it's just inconvenient to
use with grep *.

Re: [9fans] bug in exportfs

[lucio]

> Yes, although that convention isn't in Plan 9, and it might be
> worthwhile reconsidering how and why it is used.  If for configuration
> files, perhaps they should be stored elsewhere; if for access control
> (eg, .htaccess), perhaps groups would be better, with dynamic group
> membership providing the effect of an access control list.

Charles, I think Kenji has a point and you are diverting the
discussion .

Whereas I agree that the leading-dot convention ought to be buried, in
reality (a) it is not going to just go away and (b) if it was so
readily accepted, it must have fulfilled a need.

But that's history.  When exporting a file system, as Kenji points
out, things may break if we remove features.  At the same time,
documenting and, if necessary, implementing a different approach based
on a custom namespace seems like a great idea and may at least stop
further abuse of the filtering that, it seems to me, we cannot
eliminate without risk of possible pain.

I do doubt very much that retrofitting will take place, but one can hope.

Lucio.

Re: [9fans] bug in exportfs

[Charles Forsyth]

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

> 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.
>

Yes, although that convention isn't in Plan 9, and it might be worthwhile
reconsidering how and why it is used.
If for configuration files, perhaps they should be stored elsewhere; if for
access control (eg, .htaccess), perhaps
groups would be better, with dynamic group membership providing the effect
of an access control list.

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.

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.
>>
>

Re: [9fans] bug in exportfs

[Charles Forsyth]

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.

Re: [9fans] bug in exportfs

[Prof Brucee]

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.
>

Re: [9fans] bug in exportfs

[arisawa]

No.

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/

have you get solution?

> 2015/12/22 18:25、Peter Hull  のメール：
> 
> Mr Arisawa,
> Did you get any answers to this?
> Peter
> 
> 
> On Thu, 17 Dec 2015 at 13:06 arisawa  wrote:
> Thanks for your replay.
> however I don’t understand the intention of the manual.
> real needs in exporting is to export some different directories.
> it is impossible to do so under current code.
> can anyone show an example that exports two or more directories?
> 
> > 2015/12/17 20:40、Peter Hull  のメール：
> >
> > On Wed, Dec 16, 2015 at 11:31 PM, arisawa  wrote:
> >> It seems cpu command is buggy in -P option.
> >> the sources of the problem is in command option -P of exportfs.
> >
> > I had a look at the manpage for exportfs(4), it says: "For a file to
> > be exported, all lines with a prefix + must match and all those with
> > prefix - must not match." (http://man.9front.org/4/exportfs)
> >
> > So isn't the original code correct according to the manpage? If any of
> > the regexps in 'include' fail to match, the function returns -1, then
> > if any in 'exclude' do match, -1 is returned.
> >
> >> patternfile sample
> >> + /usr/arisawa
> >> + /usr/glenda
> >> - /adm
> >> - /sys/log
> >> - /mail
> >> - /usr/.*
> >>
> > Is this sample invalid - no path could match /usr/arisawa and
> > /usr/glenda at the same time?
> >
> > Pete
> 
> I said:
> 
> > int
> > excludefile(char *path)
> > {
> >   Reprog **re;
> >   char *p;
> >
> >   if(*(path+1) == 0)
> >   p = "/";
> >   else
> >   p = path+1;
> >
> >   DEBUG(DFD, "checking %s\n", p);
> >   for(re = include; *re != nil; re++){
> > - if(regexec(*re, p, nil, 0) != 1){
> > + if(regexec(*re, p, nil, 0) == 1){
> >   DEBUG(DFD, "excluded+ %s\n", p);
> > - return -1;
> > + return 0;
> >   }
> >   }
> >   for(re = exclude; *re != nil; re++){
> >   if(regexec(*re, p, nil, 0) == 1){
> >   DEBUG(DFD, "excluded- %s\n", p);
> >   return -1;
> >   }
> >   }
> >   return 0;
> > }
> >
> >
> > patternfile sample
> > + /usr/arisawa
> > + /usr/glenda
> > - /adm
> > - /sys/log
> > - /mail
> > - /usr/.*
> 
> however this code has still a problem.
> 
> trailing ‘/‘ is removed in p even if p is a directory.
> assume we have users:
> /usr/rob
> and
> /usr/robin
> then we cannot export only /usr/rob.
> if we wish control this problem, we need tailing ‘/‘ for directory.
> then the code should be
> 
> excludefile(char *path)
> {
> Reprog **re;
> char *p,*s;
> Dir *dir;
> 
> if(*(path+1) == 0)
> p = "/";
> else
> p = path+1;
> 
> s = p + strlen(p) - 1; /* tail */
> dir = dirstat(p);
> /* should not be nil */
> if((dir->mode)){
> /* we have room to append '/'
> *  look makepath() in exportfs.c */
> *++s = '/';
> *++s = 0;
> }
> 
> DEBUG(DFD, "checking %s\n", p);
> for(re = include; *re != nil; re++){
> if(regexec(*re, p, nil, 0) == 1){
> DEBUG(DFD, "excluded+ %s\n", p);
> return 0;
> }
> }
> for(re = exclude; *re != nil; re++){
> if(regexec(*re, p, nil, 0) == 1){
> DEBUG(DFD, "excluded- %s\n", p);
> return -1;
> }
> }
> return 0;
> }
> 
> then patternfile sample become:
> 
> + /usr/arisawa/.*
> + /usr/glenda/.*
> - /adm/
> - /sys/log/
> - /mail/
> - /usr/.+
> 
> adding tailing ‘/‘ in p makes the pattern file incompatible to existing one.
> I don’t know it is better to do so.
> 
> 
> 

Re: [9fans] bug in exportfs

[arisawa]

Thanks for your replay.
however I don’t understand the intention of the manual.
real needs in exporting is to export some different directories.
it is impossible to do so under current code.
can anyone show an example that exports two or more directories?

> 2015/12/17 20:40、Peter Hull  のメール：
> 
> On Wed, Dec 16, 2015 at 11:31 PM, arisawa  wrote:
>> It seems cpu command is buggy in -P option.
>> the sources of the problem is in command option -P of exportfs.
> 
> I had a look at the manpage for exportfs(4), it says: "For a file to
> be exported, all lines with a prefix + must match and all those with
> prefix - must not match." (http://man.9front.org/4/exportfs)
> 
> So isn't the original code correct according to the manpage? If any of
> the regexps in 'include' fail to match, the function returns -1, then
> if any in 'exclude' do match, -1 is returned.
> 
>> patternfile sample
>> + /usr/arisawa
>> + /usr/glenda
>> - /adm
>> - /sys/log
>> - /mail
>> - /usr/.*
>> 
> Is this sample invalid - no path could match /usr/arisawa and
> /usr/glenda at the same time?
> 
> Pete

I said:

> int
> excludefile(char *path)
> {
>   Reprog **re;
>   char *p;
> 
>   if(*(path+1) == 0)
>   p = "/";
>   else
>   p = path+1;
> 
>   DEBUG(DFD, "checking %s\n", p);
>   for(re = include; *re != nil; re++){
> - if(regexec(*re, p, nil, 0) != 1){
> + if(regexec(*re, p, nil, 0) == 1){
>   DEBUG(DFD, "excluded+ %s\n", p);
> - return -1;
> + return 0;
>   }
>   }
>   for(re = exclude; *re != nil; re++){
>   if(regexec(*re, p, nil, 0) == 1){
>   DEBUG(DFD, "excluded- %s\n", p);
>   return -1;
>   }
>   }
>   return 0;
> }
> 
> 
> patternfile sample
> + /usr/arisawa
> + /usr/glenda
> - /adm
> - /sys/log
> - /mail
> - /usr/.*

however this code has still a problem.

trailing ‘/‘ is removed in p even if p is a directory.
assume we have users:
/usr/rob
and
/usr/robin
then we cannot export only /usr/rob.
if we wish control this problem, we need tailing ‘/‘ for directory.
then the code should be

excludefile(char *path)
{
Reprog **re;
char *p,*s;
Dir *dir;

if(*(path+1) == 0)
p = "/";
else
p = path+1;

s = p + strlen(p) - 1; /* tail */
dir = dirstat(p);
/* should not be nil */
if((dir->mode)){
/* we have room to append '/'
*  look makepath() in exportfs.c */
*++s = '/';
*++s = 0;
}

DEBUG(DFD, "checking %s\n", p);
for(re = include; *re != nil; re++){
if(regexec(*re, p, nil, 0) == 1){
DEBUG(DFD, "excluded+ %s\n", p);
return 0;
}
}
for(re = exclude; *re != nil; re++){
if(regexec(*re, p, nil, 0) == 1){
DEBUG(DFD, "excluded- %s\n", p);
return -1;
}
}
return 0;
}

then patternfile sample become:

+ /usr/arisawa/.*
+ /usr/glenda/.*
- /adm/
- /sys/log/
- /mail/
- /usr/.+

adding tailing ‘/‘ in p makes the pattern file incompatible to existing one.
I don’t know it is better to do so.

Re: [9fans] bug in exportfs

[Peter Hull]

On Wed, Dec 16, 2015 at 11:31 PM, arisawa  wrote:
> It seems cpu command is buggy in -P option.
> the sources of the problem is in command option -P of exportfs.

I had a look at the manpage for exportfs(4), it says: "For a file to
be exported, all lines with a prefix + must match and all those with
prefix - must not match." (http://man.9front.org/4/exportfs)

So isn't the original code correct according to the manpage? If any of
the regexps in 'include' fail to match, the function returns -1, then
if any in 'exclude' do match, -1 is returned.

> patternfile sample
> + /usr/arisawa
> + /usr/glenda
> - /adm
> - /sys/log
> - /mail
> - /usr/.*
>
Is this sample invalid - no path could match /usr/arisawa and
/usr/glenda at the same time?

Pete