Noah,
Consider a "Trac farm" with couple of projects managed by different
peoples. It may be not the typical case but illustrative one.
As "farm" admin I would like to have (e.g.)
AccountManager plugin enabled in all projects by default;
TracMenus plugin allowed to enable;
and be able to disable SomeBad plugin for all projects at once
(e.g.because of recently found vulnerability).
(see also below)
On 2010-10-11 01:58, Noah Kantrowitz wrote:
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?".
You mean virtualenv python package? What trac doc says about? Is it
supported? For me "default" means the way recommended and therefor
supported by Trac developers.
Everything else is hacks (e.g. currently, I have a separate python
instance for Trac)
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.
Let me clarify - I don't speak about possible injury of a server hosting
Trac. It should be controlled on different level and out of Trac
developers responsibility.
But It's also important to prevent damage or exposition of Trac data
(e.g. private wiki page) and it's the meaning of "security" in this thread.
So I'm saying that pinky admin could *allow people who don't have raw
filesystem access* break something.
e.g. we have SomePlugin that known to be vulnerable, but we have to use
it in a project.
Currently nothing prevents admin of other project enable it for its
own env.
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.
e.g.
A plugin developer type: cp myplugin.py myplugin_old.py
and than forget to delete myplugin_old.py with plenty of debug printing.
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.
Hmm. I think we call the idea of having all related things in one place
"encapsulation" and it isn't ugly. (see below)
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.
OK. I may miss something. Python supports default module entry point and
Trac could rely on it and don't require egg if we have the only
component in a multi-file module.
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?
No. I don't try to forbid inheritance, I want to put it under control.
With multiple plugins directories I can maintain fine-grained permission
on each of them either with plugins.ini (below) or with OS ACL
2. No autoenable
This just makes life difficult for simple, one-env sites.
Really? It's either one-line in ini file or couple of mouse clicks in
admin panel.
Debugging issues like one with myplugin_old.py above eats much more time.
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?
We should separate trac core (i.e. controlled and supported by trac
team) information from one provided by third-party, untrusted plugins to
avoid possible conflicts and save support efforts.
e.g. some plugin chose [subnav] as a name for it's section but Trac 0.14
want to use it also for it's own purpose.
With the single config file Trac developers should care about - at
least mention this conflict in upgrade notes.
Things become ever worse if we edit ini file trough web ui, bad
plugin could damage system information and make whole project
unusable.
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)?
Nope. per-directory plugins.ini lists maximum possible permissions, per
project plugins.ini allows to narrow permissions down if necessary.
e.g. /opt/trac/plugins.ini has:
AccessManager=autoenabled
TracMenus=enabled
BadPlugin=disable
/proj/conf/plugins.ini has:
AccessManager=disabled
TracMenus=enabled
BadPlugin=enabled /*ignored*/
-Dmitry
--
Dmitry Samersoff
[email protected], http://devnull.samersoff.net
* I do want to change the world, I don't want the world to change me
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
