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 event-triggering subject (if available) as a property to > > the > > > >> event by default, so the handlers could easily recreate the > > session > > > >> by using JAAS doAsPrivileged(). > > > >> > > > >> Would that make sense? > > > >> > > > >> Best greetings > > > >> Lars > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
