[4suite-dev] URIs in the repo, revisited (addendum)

Uche Ogbuji uche.ogbuji at fourthought.com
Wed Dec 11 18:33:15 MST 2002


On Wed, 2002-12-11 at 18:43, Mike Olson wrote:
> > > >From a security standpoint, a don't like the ability for documents to get 
> > > access with the server's system access to a file on the host system.  Given 
> > > that, it would then be possible to implement the file scheme as the way into 
> > > the repository, since the file scheme is defined as as being machine 
> > > dependent anyway.
> > 
> > I see the security implications, but I think that admins should be able
> > to set security policy so that they can allow access to the local paths
> > on machine at their discretion.  This is similar to the Java run time
> > approach.
> 
> I don't think that they can.  Unless we add a "LocalDocumentRoot"
> configuration option.

Well, of couyrse we'd have to add facility for this.  I didn't say that
they could do so with 4Suite as it is.

A "LocalDocumentRoot" option would be one way.  I would not want it to
be yes/no, but rather a list of 4ss users who have permission to access
local file system.


> > I do not think we should use file: URLs to mean repo paths.  It would
> > not be illegal, but I think it would be confusing.  I certainly think of
> > file URLs separately than I think of repo paths.
> 
> I agree.  Also, it could be desirable to allow file URIs to access the
> local machine.

Yes.  There are cases where file:/// *always* will need to acess the
local file system.  Foremost example is in the src param of 4ss command
lines.


> > I do think I have a compromise, though.
> > 
> > Why don't we define a "virtual" host name for the repo, which the user
> > sets up at 4ss init time (we can offer a default, such as "4ssrepo"
> > 
> > Then we can use file:// URLs for the repo, but using the special host
> > name:
> > 
> > file://4ssrepo/ftss/data
> > 
> > Would point to what you expect
> > 
> > file:///home and the dodgy file:/home
> > 
> > Would still be local paths, even though they may be blocked by security
> > policy.
> > 
> 
> I don't like this.  too confusing.

To me it is less so than any of the alternatives.

> I think we should either allow or
> not allow access to the local file system.

I disagree.  I think this is too rigid.  We should support flexible
policy.  If we always disallow, we lose a lot of flexibility.  I use
file:/// quite often in my apps.  The recent docbook/PDF demo is just
one example.  I know Evan Lenz makes heavy use of them in his 4Suite app
as well, as does Chime.  If we always allow, then we will have security
problems.

We should give the admin the tools and ability to set policy.  It is
really their responsibility.


> If we allow access then we
> need to allow sys admins a way to restrict access to portions of the
> file system.

That's another consideration, perhaps to be considered in addition to
restriction by user.


> -- 
> Uche Ogbuji                                    Fourthought, Inc.
> http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
> Tour of 4Suite - http://www.xml.com/pub/a/2002/10/16/py-xml.html
> Proper XML Output in Python - http://www.xml.com/pub/a/2002/11/13/py-xml.html
> RSS for Python - http://www-106.ibm.com/developerworks/webservices/library/ws-pyth11.html
> Debug XSLT on the fly - http://www-106.ibm.com/developerworks/xml/library/x-debugxs.html




More information about the 4suite-dev mailing list