Comment 1 for bug 1961458

Thanks for raising this, I don’t really understand the implication of the directory change as then, any user process can create things in that directory, but as this directory is only then dealt by user process, this is fine?

Let me explain to you what happens to user scripts:
- adsysd get the policies, and for each user, copy the scripts in their own directory, with the UID of the user so that they will be to execute it. Note that machine scripts won’t change any UID. If the directory already exists, nothing is done (that prevents refreshing machine scripts until log off, see below).
- then, on log on, there is a systemd user script which execute "adsysd run-scripts", a separate process, as the user thus, which takes that directory and executes all scripts one after another, as the user
- finally, on log off, the systemd service will stop, and ExecStop will rerun adsysd run-scripts, still as the user, but for logoff (the script list may be different). Then, it will delete the user directory.
-> That way, next logon, adsys will reinstall new version (or maybe the same that were cache) scripts, ready to be executed.

So, we need to delete that directory on logoff. This directory will never have scripts executed as root (apart from machine scripts, which is totally different as we don’t change the owner for them). And anyway, those scripts are executed by a systemd job, not by the adsysd "root" daemon itself.

Does it make sense? Happy to have a chat to:
1. Understand the security issue (let’s use this to learn something, especially dark corners of security :p)
2. To see how we can safely fullfil our needs.