Hi Konrad As I said, Oak out of the box doesn't mandate a group representation of the everyone principal to exist.
In AEM it is created with a content package (or repoinit) which results in a regular call to UserManager.createGroup. see also https://jackrabbit.apache.org/oak/docs/security/user/default.html#everyone-group The code should have a null check. Even if the group were to be created in the UserInitializer it could be removed for a particular session (transiently) and then the call would still return null. So fixing the code is the right choice as changes in Oak would not help in this situation. Hope that helps Angela ________________________________ From: Konrad Windszus <[email protected]> Sent: Thursday, June 13, 2024 19:43 To: [email protected] <[email protected]> Subject: Re: Authorizable for EveryonePrincipal EXTERNAL: Use caution when clicking on links or opening attachments. I meanwhile found https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/UserInitializer.java which creates both the admin and the anonymous user, but haven’t found out yet how “everyone” is being created. > On 13. Jun 2024, at 19:30, Konrad Windszus <[email protected]> wrote: > > Hi Angela, > Thanks a lot for your input. > As it turned out in some instances the according “everyone" authorizable has > been removed by mistake and some code cannot deal with that (due to missing > null checks). > I am wondering though who Jackrabbit creates the “everyone” authorizable in > the first place, and why it isn’t being restored after a restart > automatically. > > In Sling usually such setup is done via repoinit, but I guess in Oak there > should also be some kind of repo initialization which automatically restores > the most essential parts for running Oak in case of a restart, > Maybe we can improve Oak to automatically fix such user mistakes. > > Do you have some pointers to the code which creates the “everyone” > authorizable in the first place? > Thanks, > Konrad > > >> On 13. Jun 2024, at 18:53, Angela Schreiber <[email protected]> >> wrote: >> >> Hi Konrad >> >> There has been no change in that area for ages. >> >> Oak out of the box does not mandate a Group 'everyone' to exist in the user >> management. It will however always exist if you retrieve it through >> Principal Manager in the default implementation. So, >> >> >> * >> every user/group accessible through user management API will have a >> principal attached that is also accessible through principal management API >> * >> no every principal accessible through the principal management API is >> guaranteed to be backed by a user/group in user management. >> >> Reason: principals are required for access control setup. They may come from >> any source plugged into Oak.... and one source of principals is user/groups >> stored in the repository. >> >> AEM out of the box will have a group 'everyone' installed.... but if you >> chose to remove it, the access control evaluation and principal resolution >> for your logged in user would still work. >> So, testing for the lookup of the group to null, would just be defensive >> programming. >> >> Hope that helps >> Angela >> >> >> ________________________________ >> From: Konrad Windszus <[email protected]> >> Sent: Thursday, June 13, 2024 17:07 >> To: [email protected] <[email protected]> >> Subject: Authorizable for EveryonePrincipal >> >> EXTERNAL: Use caution when clicking on links or opening attachments. >> >> >> Hi, >> Was it always the case that the “everyone" principal could not be resolved >> to an Authorizable via >> org.apache.jackrabbit.api.security.user.UserManager.getAuthorizable(<EveryonePrincipal>)? >> I found several places in AEM code where the return value of >> UserManager.getAuthorizable(Principal) is unconditionally dereferenced. >> >> Is the null return value a new behaviour or has it always been like that? >> >> Thanks, >> Konrad >
