Just to be cristal clear, I'm absolutely not against doing something in
this space and I totally agree that its worth investing , but I doubt that
there is a general out of the box solution which magically works the way
you want without changing the job creator and the consumer. Magic and
security usually doesn't play well with each other. In addition, the job
might be executed on a totally different system.
So far I only see the manual one where both, the creator and the executor
of a job are aware of the problem and do the right thing.
But maybe someone has a clever idea and comes up with a PoC.
Carsten
2014-05-15 11:25 GMT+02:00 Christian Keller chkel...@adobe.com:
-Original Message-
From: Carsten Ziegeler [mailto:cziege...@apache.org]
Sent: Mittwoch, 14. Mai 2014 19:35
To: dev@sling.apache.org
Subject: Re: Events, Jobs and admin sessions
Yes, I think there is no general solution. This has to be done on a job
by job basis. Usually the code starting a job and consuming the job
later on are related, so if a job consumer needs to read from the
resource tree with the user rights this has to be defined within the
job and the job producer has to add the corresponding information as
properties to the job. The consumer can then simply fail if this is
missing.
In this sense, the subject is treated the same as e.g. the path
pointing to the data in the resource tree.
I think it is a valid and general request to wish that a Job is executed
with the same permissions as the caller.
Eg. imagine a scheduled Job.
You could even reason for security reasons a Job MUST be done with the
same permission.
Else if I can start a Job that does something I'm not denied it results in
me being allowed.
Eg. If there is a System.exit() Job and I'm anonymous.
I think the general solution is to call the Job-Processor in the
AccessControlContext of the Job creator.
A related topic, I have to deal with, is that I like to execute something
on an org.osgi.*.EventHandler with the Permissions for the Event-Generator.
Eg. User A added a Resource.
In this case the EventGenerator and EventHandler are unrelated.
But still they don't want to exceed the privileges of the original Event.
Especially in Collaboration Application but genarally in a Everything is
Conent Repository environment. Imagine a Replication on Modification
Service, shouldn't the Service that listens to the Modification Event fail
to Replicate if the one that made the modification does not have
Replication privilege as default. Allowing and thus extending the privilege
is a valid case to, but it should be done explicitly and not per default
For the event case I do not have a solution at hand. It digs into Osgi /
Felix I'm not firm with.
But as there is need and often use for it, I would opt to reserve time for
it if we come to the conclusion it is worth it.
Regards
Christian
Regards
Carsten
2014-05-14 15:49 GMT+02:00 Lars Krapf lkr...@adobe.com:
Hello Carsten
Thanks for your reply.
No, I don't see an obvious solution either.
It's just that while reviewing the loginAdmin() usages, I discovered
that a lot of the cases are based on this problem, and I was hoping
for a solution that is as generic as possible.
For the jobs, I could imagine an extension of the JobManager API that
allows passing the subject. The resource resolver factory could then
take the event/job as a parameter and return a resolver with the
privileges of the corresponding subject.
For the events, the situation seems to be even more complicated
because usualy the event is not created manually, and I'm not sure if
it is possible to assign a specific subject to an event in many
cases.
The alternative is to use a service-user in the consumer who has
access to the respective payload, which somehow looks wrong to me
from
a security perspective.
Well.. Ideas very welcome :)
Best greetings
Lars
On 13.05.2014 22:57, Carsten Ziegeler wrote:
Hi Lars,
I see your point, I don't see right now how a general approach
could
look like. However, the creator of a job could add the subject as a
property
to
the job and the consumer can use this value to create a resource
resolver based on that value. But I think this has to be done on a
job by job
base.
Or do you see a general mechanism which always gets the subject of
the sender?
Carsten
2014-05-13 17:21 GMT+02:00 Lars Krapf lkr...@adobe.com:
Hello list
When processing events and jobs, the corresponding subject
triggering the event usually gets lost. This lead to event
handlers
/ job consumers often operating with administrative
sessions/resolvers to do their work, which in turn can lead to
privilege escalations.
A possible solution to this problem could be to add a
serialization
of the
