[Freeipa-users] Re: Check ticket expiration for all users

Thanks a lot Alexander. I have some follow up questions, > On 23 Mar 2023, at 14:50, Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote: > > On to, 23 maalis 2023, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote: >> Hi, >> >> We use RHEL 8 with kerberos, and we are using NFSv4 for mounting home >> directories. >> >> We have experienced that some machines become unresponsive if a user >> has a job that writes to the home directory after his ticket has >> expired after the default lifetime (7 days in our case). >> >> While we are looking for ways to allow people to automatically get new >> tickets, we also want to have a mechanism to log users out if their >> tickets are too close expiration (as well as all their jobs and cron >> jobs). >> >> Is there a way to get the expiration date for user tickets for a given >> user with for example “klist", or only the user himself can get that >> info? > > klist already lists the expiration date and time. You need to parse that > if you want to know it. As long as you have access to the ccache (e.g. > klist runs within the user session scope or you can specify the ccache > explicitly and have access to it), you have that information. We use KCM, and with a quick test I saw that, as root, I don’t get to read much, and I don’t get to know what’s the cache id. Any idea on how to circumvent that?

> systemd gives you a way to force out logout for a service: > > RuntimeMaxSec= > Configures a maximum time for the service to run. If this is > used and the service has been active for longer than the > specified time it is terminated and put into a failure state. > Note that this setting does not have any effect on > Type=oneshot services, as they terminate immediately after > activation completed. Pass "infinity" (the default) to > configure no runtime limit. > > If a service of Type=notify sends "EXTEND_TIMEOUT_USEC=...", > this may cause the runtime to be extended beyond > RuntimeMaxSec=. The first receipt of this message must occur > before RuntimeMaxSec= is exceeded, and once the runtime has > extended beyond RuntimeMaxSec=, the service manager will > allow the service to continue to run, provided the service > repeats "EXTEND_TIMEOUT_USEC=..." within the interval > specified until the service shutdown is achieved by > "STOPPING=1" (or termination). (see sd_notify(3)). The problem here - as I see it - is to start the count dynamically, in case the user, for example, renews his ticket by entering his password on another ssh session.

> > and logind gives a way to force killing processes on user's logout: > > KillUserProcesses= > Takes a boolean argument. Configures whether the processes of > a user should be killed when the user logs out. If true, the > scope unit corresponding to the session and all processes > inside that scope will be terminated. If false, the scope is > "abandoned", see systemd.scope(5), and processes are not > killed. Defaults to "no", but see the options KillOnlyUsers= > and KillExcludeUsers= below. > > In addition to session processes, user process may run under > the user manager unit user@.service. Depending on the linger > settings, this may allow users to run processes independent > of their login sessions. See the description of enable-linger > in loginctl(1). > > Note that setting KillUserProcesses=yes will break tools like > screen(1) and tmux(1), unless they are moved out of the > session scope. See example in systemd-run(1). Thanks. This is also a good tool. But I guess we need to find a way to scan possible cron jobs that starts exactly when the user isn’t logged in.