IdP files/directories permissions "reset"

[Youssef GHORBAL]

Awsome! Thanks for the input.

Youssef
--------------
> On 3 Apr 2025, at 20:23, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> There's no reference I recall about it, and I don't have time to create anything formal atm. It follows fairly common sense rules from my recollection.
> 
> The container has to be able to read everything in the installation, and write/create logs and any directories chosen for caching metadata files with some of the resolvers.
> 
> Anything else is local security decision making, obviously keys and secrets should not be readable by much other than the container normally.
> 
> The installation tools obviously need to be able to write to most places but that's a matter of the account under which they're run and of course it's not mandatory to do that in production, depends on one's model for deployment of plugins or upgrades.
> 
> The container is obviously a whole different matter driven by those specifics, but it's largely similar/obvious, only logs and tmp have to be writeable.
> 
> The umask of the process would govern exactly how it creates files such as logs or the metadata cache files in both contexts.
> 
> I would imagine most people using a split account model would have the shell identity as one account and the container as another, so one would probably use group permissions to grant the container account the needed access, leaving most files owned by the shell account save the files created at runtime. That's what I do, but I don’t know that it's the only way.
> 
> The IdP doesn't do a whole lot about any of this save I guess for Rod's reference to that specific class when it does some specific operations, but it doesn't adjust much that I'm aware of if it's not actively creating directories.
> 
> You can always run the installer over top and just see if it fixes anything up but I doubt it will change too much.
> 
> -- Scott
> 
>