 |
 |
Unfortunately, it's not that simple. It is the responsibility of the application to verify that the admin has kept the file secure. It is the responsibility of the admin to secure the file. This is exactly what xrootd does and is in keeping with many other systems that require that files be secured. On Wed, 29 Mar 2023, R. P. Taylor wrote: > Is keeping the keytab file secure the responsibility of xrootd or the administrator? I think an application should take some reasonable precautions and/or print helpful warnings, but it is ultimately the responsibility of and should be under control of the administrator. Likewise for ensuring the group is a singleton. xrootd can not absolutely ensure the confidentiality of the keytab file. I could always accidentally paste it on github or something :) > >> if root created the file it can just as easily assign the ownership to daemon. > > That is [not possible](https://github.com/kubernetes/kubernetes/issues/81089#issuecomment-587174133)](url) in this case, because the secret is managed by the kubelet and the file is mounted into all containers of a pod, but each container in a pod may have a different identity context which would lead to UID conflicts. Besides, this is not running on a traditional server where there are other users. It is running in a pod where there is only one parent process running with a completely arbitrary UID and GID. It's kind of like the 'O' field in 'UGO' is irrelevant because it is an isolated environment with no other users (or you can think of the processes allowed to run in the container as being the "group" of the container), the U field has to be root as explained above, so the G field is used for ownership of the file. > U -> - > G -> U > O -> G > > Some applications (such as Postgres and arcproxy) which had assumptions about the security context of a traditional server have relaxed those requirements a bit to allow admins more control in how they deploy services (for example on Kubernetes) and to adapt to being more container-native. > > If the pod crashes it will be restarted automatically and any transient files will be lost. The pod could be instrumented to retain core files though, e.g. in /mgm. But either way the concept of a home directory doesn't really apply in this context. > > Thanks for your consideration! > > -- > Reply to this email directly or view it on GitHub: > https://github.com/xrootd/xrootd/issues/1982#issuecomment-1489068184 > You are receiving this because you commented. > > Message ID: ***@***.***> -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1982#issuecomment-1489270119 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1