Thanks a lot Alexander. I have some follow up questions, > On 23 Mar 2023, at 14:50, Alexander Bokovoy <[email protected]> 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 [email protected]. 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. Best, Francis > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
