I think there are two main issues to clarify.
1) Python lacks any form of sandboxing so if someone can manipulate
plugins they can do anything Trac can do and there is _no_ way to
prevent that. It is a limitation of Python and unless something like
Brent Cannon's restricted interpreter work ever ends up in core making
people jump through hoops (example, multiple configuration files) is
pointless and annoying.
2) Trac has always and will always been designed with people running a
single-environment site in mind. That isn't to say that we would never
make a compromise, but things are stacked pretty heavily in favor of
single-project setups since that comprises the vast majority of the
userbase. A setup like you mentioned with Trac being used for
SourceForge-style hosting is exceedingly rare, though it just so
happens that one of most active core developers is in charge of such a
site as part of his day job.
I think there is also some confusion about how plugin loading works
(re: the global default comment). Setuptools will examine every folder
on sys.path (and $ENV/plugins and any configured plugins_dir's)
looking for .egg-info folders or egg files containing EGG-INFO data.
Any such package with a [trac.plugins] group in its entry points will
be loaded and returned. Of note, this means that module-level code in
any package that declares trac.plugins entry points will be run
regardless of the enable status. I am trying to make it clear that
disabling a plugin isn't meant to be a security-grade check. The only
way to ensure that a plugin is running no code is to entirely remove
it from the path. Using virtualenv (which all sane people running
Python webapps should be using I hope) this is easy since you can just
delete the offending file from that particular packages folder. The
enable/disable settings only kicks in all the way down the line when
iterating over an extension point. As for altering the auto-load
settings, you could probably do that in a plugin without that much
trouble. If you are actually interested in doing this, try finding me
on the IRC channel or contact me off-list.
--Noah
On Oct 11, 2010, at 9:04 AM, Dmitry Samersoff wrote:
Grzegorz,
The most important part of proposal - multiple plugins directories
counted explicitly in trac.ini and I guess it has minimal impact.
i.e. we can have something like
plugins_dirs = /a,/b,/c
plugins_autoenable_dirs=/a,/c
and keep everybody satisfied ;)
(see also below)
On 2010-10-11 15:45, Grzegorz Sobanski wrote:
Currently nothing prevents admin of other project enable it for
its
own env.
Hmm, just put in in envdir/plugins?
Then it's not available to other environments.
Unless someone "inherits" it ... There are some symlink/permissions
tricks that solve this problem, but I would like to see an instant
solution rather than tricks.
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.
And what if he types: rm *?
rm * is not an issue as it doesn't lead to security whole. Just some
extra work for backup team.
Also how often you here that someone did rm * on the hosting ?
Incident with forgotten old or back files happens once a month and
cost a fortune.
Etc, etc
As Noah said, if someone has fs access, or can deploy plugins
developed
by themselves, they can break everything.
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.
A would say: sensible defaults.
If someone puts a plugin in environment, he surely wants it enabled,
so IMO it should be enabled by default. It's a very sensible
solution.
It's very sensible solution for small system where plugin developer,
trac admin and web qa is the same person.
Debugging issues like one with myplugin_old.py above eats much more
time.
But only for you, and enabling all modules would have to be done by
hundreads of other people, sorry. Plus all the questions on ML "why
my
plugin doesn't work".
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.
Trac doesn't sandbox plugins, so you *have to* trust plugins, because
they can do everything.
Yes and it's a trac design issue. But it couldn't be addressed without
significant efforts, ini separation is just one simple step forward.
I don't see how separating enabling modules from trac.ini helps with
anything, sorry.
Trac is clearly devided into core and plugins and it's one of
biggest advantage of trac. i.e. if I turn off all plugins I have
reasonable and secure enough environment.
But bad plugin (e.g. with incorrect implementation of
IAdminPanelProvider) could destroy whole project configuration
I think you may have some valid points about probles in config like
"trac farm", but the proposed solution IMO are not good defaults for
trac, at least some of them.
I never pretend to be an oracle .. Just giving to trac community a
subject to think.
-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
.
--
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.
