Am Sonntag, 27. Oktober 2024, 10:35:30 CET schrieben Sie: > Tobias Rupf <tobias.r...@gmx.de> writes: > > > Am Samstag, 26. Oktober 2024, 20:37:06 CET schrieb Simon Josefsson: > >> Tobias Rupf <tobias.r...@gmx.de> 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. > I'm using it gssproxy for kerberos with nfsv4 and the config file /etc/gssproxy/99-nfs-client.conf is telling to use this directory in it's cred_store line: cred_store = ccache:FILE:/tmp/gssproxy/clients/krb5cc_%U A similiar file is included in the doc as example: /usr/share/doc/gssproxy/examples/99-network-fs-clients.conf Of course you could modify the line to use the /tmp directory without sub directories, or add a comment to the file to make the user aware, that he must make sure himself to create the subdirectories...
> >> > 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. OK, I see, one can see it that way. In my opinion I would think to use it for all those as I don't see any reason why to enable it for one service but not for the other. You can still leave a service out by just not configuring a client keytab for it. It just took me some days to figure all that out and I'd like to make live easier for others. -------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
