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

[Mike Olson]

> 
> 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've been thinking about this some more.  I think we should just disable
file system access (because it is a security hole) and leave it at
that.  We have no requests from anyone (users or clients) to drive this
and it looks like we are comming up with yet another very
flexible/complex (to the point of being unusable) 4Suite feature "just
because we can".

I vote just to restrict access and call it a day.  If we find a real
need for file system access we can implement it later.

Mike

> 
> 
> > > 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
-- 
Mike Olson                                Principal Consultant
mike.olson at fourthought.com                +1 303 583 9900 x 102
Fourthought, Inc.                         http://Fourthought.com 
PO Box 270590,                            http://4Suite.org
Louisville, CO 80027-5009, USA
XML strategy, XML tools, knowledge management