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?
Best,
Francis
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.
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)).
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 a lot Alexander. I have some follow up questions,
On 23 Mar 2023, at 14:50, Alexander Bokovoy abokovoy@redhat.com 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.
Best,
Francis
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On to, 23 maalis 2023, Francis Augusto Medeiros-Logeay wrote:
Thanks a lot Alexander. I have some follow up questions,
On 23 Mar 2023, at 14:50, Alexander Bokovoy abokovoy@redhat.com 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?
Well, 'su - user' might give you access to KCM's view of that user. Other than that, it might not accessible.
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.
Yeah, this is not something to achieve this way.
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.
Indeed.
--- Francis Augusto Medeiros-Logeay Oslo, Norway
On 2023-03-23 16:06, Alexander Bokovoy via FreeIPA-users wrote:
On to, 23 maalis 2023, Francis Augusto Medeiros-Logeay wrote:
Thanks a lot Alexander. I have some follow up questions,
On 23 Mar 2023, at 14:50, Alexander Bokovoy abokovoy@redhat.com 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?
Well, 'su - user' might give you access to KCM's view of that user. Other than that, it might not accessible.
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.
Yeah, this is not something to achieve this way.
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.
Indeed.
Thanks Alexander. So I guess that we do have to impersonate the user to get this done, anyway. I wanted to avoid that route, but if that's what it takes, so I guess that's what we'll have to do :)
Best, Francis
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Francis Augusto Medeiros-Logeay