-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/24/2010 10:24 PM, Dmitri Pal wrote:
Stephen Gallagher wrote:
> On 03/19/2010 11:21 AM, Jakub Hrozek wrote:
>> On 03/19/2010 04:09 PM, Dmitri Pal wrote:
>>> How frequently you delete users? I suspect very rarely.
>>> I do not think we should talk about a habit here.
>>> If the platform does not implement the check we should just give
> warning
>>> and proceed.
>>> We can add quite switch later if that turns out to be annoying but I
>>> doubt we should even open a ticket for this now.
>> I agree with this. A patch that warns and proceeds is attached.
>
> Could someone explain to me why we need this switch at all? If you're
> aiming to delete a user, why do you care if they're still logged in? If
> you're deleting that user, you don't want them on your system; why would
> it matter if their user suddenly disappeared out from under them?
>
> I can't really think of a reason why this would be useful, except for
> notifying the admin to do a 'killall -u <user>' first to boot the user
> off the system, but that would be better served to be done after they
> were deleted anyway.
>
> I think this isn't really a bug. I think the need for --force is
> redundant. We should always proceed with the user deletion and always
> warn that the user is still logged in if we are capable of detecting that.
>
> In other words:
>
> On platforms that support get_uid_table():
> If the user is not logged in:
> 1) Delete the user.
> If the user is logged in:
> 1) Delete the user.
> 2) Print a message stating that the user (with uid N) was logged in
> when you deleted it.
> 3) (Optional) Add a --kick flag to sss_userdel that disables the
> user's password, then invokes 'killall -u <username>' and
then
> delete the user (to avoid race conditions where a user might
> log back in immediately after being kicked)
>
>
> On platforms that do not support get_uid_table():
> 1) Delete the user.
> 2) (Optional) Add a --kick flag to sss_userdel that disables the
> user's password, then invokes 'killall -u <username>' and
then
> delete the user (to avoid race conditions where a user might
> log back in immediately after being kicked)
>
This is a different approach. Here you try to automate the operation
yourself by providing the --kick flag.
With --force flag you leave the responsibility to kick user first to the
caller.
I was thinking that shutting down users' processes before actually
deleting him might allow for a cleaner shutdown -- and perhaps remind
the admin that he should migrate or backup data or files of these
processes etc..
But you are probably right, this was perhaps trying to think too much
for the admin. I'll implement your proposal.
What you propose is better but more work.
I am not sure it is justified.
Opinions?
It is really not that much work. We already have code in place to
disable the account (locking the user in sss_usermod).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAkurPKUACgkQHsardTLnvCWB0gCcDTgZWsUTUfTCpy093Zw0zBsl
CLcAn0FF67Lxf7TvqjZd4W9jaC+bD73O
=bn+i
-----END PGP SIGNATURE-----