On Wed, Nov 18, 2009 at 12:56 AM, Allan McRae <allan@archlinux.org> wrote:
Caleb Cushing wrote:
so here's the problem I've discovered
http://xenoterracide.blogspot.com/2009/11/bypassing-disabled-accounts-with-k... < links to arch bug included posting here because I believe both kde's and arch's developers responses are less than satisfactory. This is a security bug an easy to fix without making users lives more difficult.
Oh no. It has been 1 day and my "bug" is not fixed! I must blog about it so the world listens to me...
because kde marked it invalid and the reply I received from arch suggests it's 'not a bug'. regardless I blogged about it not just because of Arch, but in case users of other distro's have a similar 'vulnerability'. I was not happy that it took me several tries and much research to disable an account effectively from gui and cli.
"I shouldn't have to disable an account in more than 1 way to disable it across the board."
Let see... one step procedures for disabling the user account
1) change password for that user
I don't want to change there password that's not at all what I'm trying to accomplish sure it would lock them out. but it's not the same as disabling the account.
2) put an asterisk "*" at the beginning of the second field (before the encrypted password) in the file /etc/shadow.
is this actually all that much different from doing a passwd -l ? which " puts a '!' in front of the encrypted password, effectively disabling the password."
3) set an account expiry date using chage
same as what I did with usermod for some reason it didn't take effect immediately (not sure why haven't retested since discovering later) this is ok but if you google disabling unix accounts you'll find quite a few references to changing the shell to /bin/false. I also swear (having trouble finding it) that I read somewhere that setting the shell to /sbin/nologin should stop users from using X or kdm.
3) userdel is permanent one step procedure that works very well...
I only wanted to lock them out, not delete them. in case I decided to re-enable later. this is also the reason the password option wasn't acceptable.
#2 is my preferred.
Allan
-- Caleb Cushing http://xenoterracide.blogspot.com