> Traditional Unix conflates authentication and authorization - if you can authenticate as a user you are authorized to use the computer, full stop.
Incorrect. Nearly every service in a Unix computer has its own authorization mechanisms, there is no blanket authorization over an entire host.
The login service has a "nologin" and "securetty" files. Sudo has its sudoers file. RSH has the .rhosts file. FTP daemons have their own authorization logic. NFS authorization options could override local filesystem permissions. Filesystem permissions defined the authorization for device files, but network services (such as CUPS) would add their own authorization mechanisms. Etc, etc, etc.
The difference between authentication and authorization has been apparent since time-sharing systems were invented. The operators were authorized to perform different operations than the bog-standard users. There hasn't been a time since the 60's that everyone was authorized the same just because they were authenticated.
> Scrambling the password works as a deauthorization mechanism solely because you strip the user of the ability to authenticate.
Doesn't work. If you're using SSH key authentication you can skip password auth. With RSH, password auth isn't required if you're coming from a trusted host defined in a .rhosts file.
> The only bulletproof way to deauthorize a user is to unperson them - delete the account.
That doesn't always work either. There may be more than one authentication system, and they may be configured to simply skip to the next authentication method if a user account is not found. So you would have to delete the account from every authentication system connected.
You have to use the prescribed deactivation method for every authentication system connected, otherwise the first auth method may skip the deactivated user but the second system would pick up its own user with that name/ID.
Incorrect. Nearly every service in a Unix computer has its own authorization mechanisms, there is no blanket authorization over an entire host.
The login service has a "nologin" and "securetty" files. Sudo has its sudoers file. RSH has the .rhosts file. FTP daemons have their own authorization logic. NFS authorization options could override local filesystem permissions. Filesystem permissions defined the authorization for device files, but network services (such as CUPS) would add their own authorization mechanisms. Etc, etc, etc.
The difference between authentication and authorization has been apparent since time-sharing systems were invented. The operators were authorized to perform different operations than the bog-standard users. There hasn't been a time since the 60's that everyone was authorized the same just because they were authenticated.
> Scrambling the password works as a deauthorization mechanism solely because you strip the user of the ability to authenticate.
Doesn't work. If you're using SSH key authentication you can skip password auth. With RSH, password auth isn't required if you're coming from a trusted host defined in a .rhosts file.
> The only bulletproof way to deauthorize a user is to unperson them - delete the account.
That doesn't always work either. There may be more than one authentication system, and they may be configured to simply skip to the next authentication method if a user account is not found. So you would have to delete the account from every authentication system connected.
You have to use the prescribed deactivation method for every authentication system connected, otherwise the first auth method may skip the deactivated user but the second system would pick up its own user with that name/ID.