Re: On PATH_MAX

[Michal Suchanek]

On 11/3/05, Christopher Nelson <address@hidden> wrote:
> > At Thu, 3 Nov 2005 09:58:01 -0700,
> > "Christopher Nelson" <address@hidden> wrote:
> > >
> > > > "Alfred M\. Szmidt" <address@hidden> writes:
> > > >
> > > > > Make it possible to set the amount a user is able to
> > > > allocate instead
> > > > > of setting any kind of static limit that is impossible
> > to get away
> > > > > from without recompiling the whole system.
> > > > >
> > > > > Arbitrary limits are poor software design, and have always been.
> > > >
> > > > I tend to agree here.  :-)
> > > >
> > > > Whether the OS architect likes it or not, applications
> > that use the
> > > > file system the way GNU Arch does _do_ exist.  And it's not up to
> > > > the OS architect to decide whether they should exist at all.
> > >
> >
> > > If you want an operating system that let's you do whatever
> > you want,
> > > you should just stick with DOS. ;-) More seriously, if you
> > wish to be
> > > actively hostile, what is stopping you from creating a path
> > as large
> > > as available memory and passing it across the protection boundary?
> > > Such an act would cause severe denial of resource as the system
> > > thrashes it's swap and spends quite a long time parsing and
> > breaking
> > > down the path.  It would likely cause the receiver to fail.
> > > Even if the receiver restarts, the hostile app could wait for it to
> > > come back and retry the same operation.  Supporting
> > arbitrarily large
> > > messages of that sort are dangerous in a silly way.  A reasonable
> > > limit is necessary.
> >
> > It's not dangerous if I don't pass the path as a string, but
> > the resource containing the path.  And the resource
> > containing the scheduling time to process the path ;)
> >
> > In other words: It is all a matter of what your trust
> > boundaries are, how your communication protocols look like,
> > and what operations you perform.
>
> Sure, but in practice how does this work?  The sending app gives you as much 
> processing time as it has to process THAT path?  Does that mean that all 
> paths are processed in a thread-per-path?  If not, how does the receiving 
> thread *practically* break up it's operations to obey that scheduling quanta? 
> If it doesn't break them up, it starves out other clients. If so, when I 
> create a path as large as available memory and then pass it to you, you 
> *STILL* have a problem.  Somehow you have to get access to that path, and 
> chances are you don't have enough virtual memory to map it in.  Even if you 
> *DO*, you still have the problem that other threads working on other paths 
> require actual physical memory (not to mention other useful apps), which 
> requires swapping in and out to allow them to work. Finally, even if that 
> doesn't cause a noticeable problem, how many sane path algorithms can 
> validate a path in place without using additional memory?  Granted, it can 
> certainly be done, but in *practice* it's unreasonably difficult.

It really depends on the protocol used.
On unix the pathname must be limited because it is used as the file
identifier in syscalls.
But notice how the filesystem really stores the files: there are two
very different structures.
The first one is a file. It has content, and an unique inode number.
Implementing this part securely is easy. Even if you cannot map the
whole file into your address space (because it is too large or you did
not get that much space) you can read it in parts.
The other structure is a directory. It is a list of (name,inode)
pairs. There is no reason why this cannot be impemented in a separate
server. And possibly in a different way. You can make (inode,inode)
pairs where one inode stores the data, and another the name. Readdir
can return a few such pairs at a time without any difficulties.
The server can even implement a filtered readdir where you give up to
one page of characters that represent the start of your desired name.
If the string is shorter than one page, it should be an exact match.
Otherwise (the less likely case) you get matching entries few at a
time.
The searching is bound by the length of the directory. You should be
able to get that length before you make the request so that you can
estimate how long it can take. Or you can traverse the directory
yourself with simple readdir. It may take some time but you always
know that you are making some progress as long as the server responds.
Note that this is much better than "I give you a name up to 1 page
long and you give me the inode". The PATH_MAX limits the depth of the
directory structure but the width is still limited only by available
memory (or disk space?). You can probably put something like 4G
entries at each out of 2K levels. Traversing that may require quite a
bit of time.


Thanks

Michal

--
             Support the freedom of music!
Maybe it's a weird genre  ..  but weird is *not* illegal.
Maybe next time they will send a special forces commando
to your picnic .. because they think you are weird.
 www.music-versus-guns.org  http://en.policejnistat.cz