On Oct 10, 2010, at 2:17 PM, Dmitry Samersoff wrote:
Hi Everybody,
My 0.2 cents as a security expert ...
Start customizing trac I'm concerned about existing plugin deployment
Concerns:
1. By default Trac plugins deployed to site-wide location it's bad
as Trac plugins has no meaning outside of trac and was not tested
outside of trac for possible conflicts and security issues.
Says who? If you mean "setup.py install" installs to site-packages by
default then I would counter "Why the heck are you not using
virtualenv?".
2. trac project admin could use any plugins he wants changing
inherit.plugin_dirs and it's uncontrollable.
So you are saying someone that has raw filesystem access to the server
could possibly break something? Yes, yes they can.
3. Any py file dropped to plugin directory will treated as a plugin
and could cause user-visible error or other security issues; from
other site it's not possible to move plugins directory outside trac
project tree (e.g. to make it accessible for dedicated python
programmer)
Again, if someone already has R/W access to the env folder, you have
bigger problems.
4. Removed plugins leave orphaned entries in trac.ini
I'll give you this one, its kind of ugly, but not all that bad in the
grand scheme of ugly config files.
5. python support __main__.py as entry point of a module, I guess
trac support for egg-less modules simplify plugin development.
I think you need to explain this a bit further. I think you are
talking about the "run a module" mechanism, not sure how that is
relevant though since plugin loading is effectively declarative, they
just need to be imported.
Proposal (IMHO, of course)
1. Multiple plugin dirs,specified in trac.conf explicitly, no
default or inherited one - e.g.
plugin_dirs=/opt/trac/plugins,~vasya/trac_plugins
Doesn't that defeat the point of having config file inheritance?
2. No autoenable
This just makes life difficult for simple, one-env sites.
3. Component config should be moved out of conf/trac.ini to conf/
plugins.ini
How does this improve anything? Wouldn't the orphaned entries just be
in a different file?
4. Each plugins dir have to contain plugins.ini with explicit list
of files to load/classes to enable or autoenable. Project admin
could explicitly disable plugin in conf/plugins.ini if it's
autoenabled, explicitly enable if it's enabled but couldn't
enable it if it's disabled.
Doesn't this conflict with #2 above? Also how is this different than
the current setup using entry points (other than being non-standard)?
5. Support for just a module directory with __main__.py as well as
egg format
6.(stage II) Each plugin should have it's own ini file instead of
trashing trac.ini
7. (stage II) Add an ability to list projects with enabled/
autoenabled/disabled status for each of them in plugins.ini
8. (stage II) Add an ability to specify required permissions in
plugins.ini
--Noah
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-...@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
