| 2 Feb 2023 |
 raitobezarius | So even if you bind it, you cannot read it because it's not a+r or you're not in the group (or it's not g+r, whatever) | 23:40:42 |
| raitobezarius | Or am I confusing it with ReadOnlyPaths | 23:40:50 |
 hexa | I don't think you need extra permissions, when systemd provides the mount for the service | 23:49:16 |
| 3 Feb 2023 |
| hexa | hm, nvm. I did indeed add SupplementaryGroup with BindPaths | 00:15:39 |
 m1cr0man | LoadCredentials isn't the best option unfortunately because it means you must always restart the service, as a reload won't reload the creds from disk. | 21:42:13 |
| m1cr0man | TemporaryFilesystem suffers the same caveat | 21:42:23 |
| m1cr0man | For things where restart is viable/standard, then LoadCredential can work quite well | 21:42:39 |
| hexa | yeah, LoadCredential= would need to inotify the original file and sighup the process or something to be useful | 22:47:36 |
| m1cr0man | Or systemd needs to provide a mechanism for reloading credential files in cases where the application will auto-reload all files itself. Like, if I could do systemctl reload httpd --credentials that would do the trick so long as credentials are reloaded before the process itself | 22:51:31 |
| hexa | how does BindPaths suffer from the same caveat, then its just a bind mount? | 22:55:13 |
| hexa | * how does BindPaths suffer from the same caveat, when its just a bind mount? | 22:55:35 |
| 4 Feb 2023 |
| m1cr0man | I was only referring to LoadCredentials. BindPaths is fine if you are also ok with extending the service user's groups in some fashion. | 11:47:57 |
| 7 Feb 2023 |
| m1cr0man | I just saw #215124, will look into it tonight | 15:19:02 |
