Felix,
That sounds like it would address the issue of accepting scripts from
trusted sources but would not, make the scripts safe as per your
original post.
On System.exit itself
I cant remember if the runtime shutdown handler can veto System.exit,
although the damage will already be done.
enabling java security feels (to me at least) like potentially hard
work, especially with all the OSGi classloaders in play.
Ian
On 22 Apr 2009, at 12:00, Felix Meschberger wrote:
Hi,
Ian Boston schrieb:
This is an interesting one for us, since all users will have write
access to the repository.
Is there an 'execute' permission in sling, or perhaps even an
equivalent
to the no execute mount option in posix. I see some extensions to the
DefaultAccessControlManager looming.
No, there is no such thing. Neither on the repository level nor on the
Sling level.
In fact such an exception can also not be enforced by the repository,
since it has no notion of "execution". I think, though, the storing
such
a permission would probably be possible and the scriping handlers we
have would have to ensure the permissions, which is not currently
done.
Regards
Felix
Ian
On 22 Apr 2009, at 11:25, Jukka Zitting wrote:
Hi,
I was thinking about the implications of giving a user write
access to
a subtree of the repository. With that access the user could now
upload a new script and create a node that invokes that script when
rendered.
What if the script contains something like System.exit(1)? Or
something even more malicious?
Do we have mechanisms for preventing attack scenarios like that?
BR,
Jukka Zitting
