Tobias Rupf <[email protected]> writes: > Am Samstag, 26. Oktober 2024, 20:37:06 CET schrieb Simon Josefsson: >> Tobias Rupf <[email protected]> writes: >> >> > I'm using gssproxy at my client for automatically getting a kerberos >> > ticket for >> > a service, without user intervention. I installed and startet the service >> > but >> > it was not working until i figured, that I need to create this directory >> > as it >> > is references in the default config file 99-nfs-client.config. And it has >> > to be >> > recreated after each restart of my client as files in /tmp do not survive a >> > reboot. >> > So I have added an override to /etc/systemd/system/gssproxy.service.d: >> > >> > [Service] >> > ExecStartPre=/bin/mkdir -p /tmp/gssproxy/clients >> > PrivateTmp=true >> >> Hi and thanks for the report. The /tmp/gssproxy/clients directory looks >> weird, where is that path coming from? I looked a bit in gssproxy >> source code but didn't find what would create it. Is this coming from >> some kerberos configuration? Could you give some step-by-step >> instructions on how to reproduce this problem, from a freshly installed >> debian system? >> > Of course this directory does not exist as systemd uses and creates > private tmp directories. You should instead find a directory like > /tmp/systemd-private-<some-id-string>-gssproxy.service-<some string> > on your system which is created by systemd at startup of gssproxy- > service. Gssproxy needs it to place krb5cc credentials there. > The override creates the neccessary sub folders inside this directory. > Without the override the subfolders are missing and gssproxy can not find > a location to place the credential-files for the users (hence gssproxy does > not create subfolders in /tmp resp. its private /tmp itself)
What is creating the files in that directory? What software and configuration is responsible for using /tmp/gssproxy/clients as the intended path? I can't find anything in the gssproxy package that refers to that path, but I may be missing it. What I suspect is that something else is configured to use that path, and that is the component that is responsible for also creating the directory. We have a good regression testing of a Apache2+gssproxy setup that is tested in debci/autopkgtest of the gssproxy package, and no extra directory is necessary there. See output: https://salsa.debian.org/debian/gssproxy/-/jobs/6490012 https://salsa.debian.org/debian/gssproxy/-/blob/master/debian/tests/gssproxy-apache Having a similar script for your use-case would be nice, to make sure it keeps working. I think your use-case is different from the apache2 use-case since you want the service to acquire user tickets? I'm not sure if getting tickets as the apache2 server on behalf of the user is possible to do, and if so maybe doing so in this script will trigger your use-case. >> > To actually be used by rpc-gssd.service a second overriide is neccessary >> > for >> > this service: >> > >> > [Service] >> > Environment=GSS_USE_PROXY=yes >> > >> > Without these two additions gssproxy was not working on my client, so I >> > think >> > they should be included in the package - or at least be mentioned in the >> > docs >> > and may be as a comment in the configuration file. >> >> I believe the requirement to add GSS_USE_PROXY is fairly well >> documented, see /usr/share/doc/gssproxy/docs/README.md.gz or URL below. >> There is a systemd service file example that matches your setup. >> >> https://github.com/gssapi/gssproxy/tree/main/docs#configuring-the-application >> > Yes it is well documented, nevertheless the override is required and I think > it > should be included in the Debian gssproxy package. With override a mean a file > should be installed in /etc/systemd/system/rpc-gssd.service.d containing the > 2 lines: > [Service] > Environment=GSS_USE_PROXY=yes > as described in my original report. A common user would expect gssproxy to > work > and to be used right after installation of the package. That's why the report > is > targeted to Debian project and not the gssproxy creator... How should the gssproxy package know that you want to use gssproxy with rpc-gssd? Gssproxy can be used with a lot of applications and GSS_USE_PROXY has to be enabled for each application the user wants to use it for. Having gssproxy add overrides unconditionally and by default for rpc-gssd, apache2, dovecot, etc seems odd to me. Some users may want to use it with apache2 and NOT rpc-gssd, and some may want to use it with rpc-gssd and NOT apache2. That's why this is configurable, I suppose. Indeed this is a bad limitation of the current gssproxy design, since it makes it harder to use, but I think it is intentional. /Simon
signature.asc
Description: PGP signature
