-
Notifications
You must be signed in to change notification settings - Fork 64
Support disabling password login via -l flag to passwd and fix exit code error in passwd #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
2f858a6 to
98c6638
Compare
|
Sorry, force push because I forgot to make the new functions |
Grimler91
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Maybe I am just not well-versed in the unix world, but why -l for removing? Is there a particular passwd implementation that has that command? On my system I have:
$ passwd --help
[ ... ]
-d, --delete delete the password for the named account
-e, --expire force expire the password for the named account
-h, --help display this help message and exit
-k, --keep-tokens change password only if expired
-i, --inactive INACTIVE set password inactive after expiration
to INACTIVE
-l, --lock lock the password of the named account
[ ... ]
passwd.c
Outdated
| case 1: | ||
| return main_set_password(); | ||
| case 2: | ||
| if (strcmp(argv[1], "-l") == 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please change to use strncmp(argv[1], "-l", 2) just to follow good practice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used strcmp since the rest of the code also uses it. Isn't the suggested use of strncmp exactly equivalent in this case? And aren't argv elements guaranteed to be nul-terminated?
But I guess it's good in case something changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, no changes for risk of out-of-bounds reads (I think). IMHO a good idea to always use safe functions nevertheless.
Only change would be that any arg -l* is then interpreted as -l also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we also have to remember that github copilot monitors everything we do here, so with strcmp we risk microsoft suing us after copilot introduces strcmp vulnerabilities in other projects
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think accepting anything starting with -l is a good idea though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a comment like this?
if (strcmp(argv[1], "-l") == 0) { // safe since argv[n] and literals are nul-terminated
|
I choose |
To quote from the -l, --lock
Lock the password of the named account. This option disables a
password by changing it to a value which matches no possible
encrypted value (it adds a ´!´ at the beginning of the password).
Note that this does not disable the account. The user may still be
able to login using another authentication token (e.g. an SSH key).
To disable the account, administrators should use usermod
--expiredate 1 (this set the account's expire date to Jan 2, 1970).
Users with a locked password are not allowed to change their
password.Shadow-Utils -d, --delete
Delete a user's password (make it empty). This is a quick way to
disable a password for an account. It will set the named account
passwordless.As the paragraph from the man page would indicate, this does not disable the account. |
|
I see. |
b82e8d2 to
cb2c0d9
Compare
|
@TomJo2000 fixed |
|
Deleting termux-auth doesn't really support empty passwords.
|
It is my understanding that since Termux is a regular Android app Would removing that file not "delete" the set password? |
|
An alternative is to accept both |
|
Since, if we consider launching Termux as a way to log in outside of the usual shadow/login mechanisms, the behavior is identical in either case |
@TomJo2000 termux-auth was never designed to be compatible with PAM or shadow-utils. Its exclusive purpose is to provide way of password-based authentication for packages So as not to expose users to danger when using remote access utilities, termux-auth was designed to be totally locked down when password is not set. Whenever This behavior differs from what you can observe on normal Linux systems where empty password in /etc/shadow permits login without authentication (no password prompt appears). |
I did not realize that was something we implemented specifically. |
This is because of Not all remote access tools have the same mechanism. Besides OpenSSH, termux-auth is being used by Dropbear and Shellinabox packages. |
sylirre
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Henrik Grimler <grimler@termux.dev>
cb2c0d9 to
934b06a
Compare
|
@sylirre fixed! |
|
I think accepting both -l and -d is the best solution |
|
Yes, better to provide |
|
Should the help message mention both or should one be the canonical form? |
|
Mentioning only one is enough. |
|
This maybe isn’t the most efficient way of comparing these but who cares, I would rather not write a state machine for this |
Note: I haven’t yet been able to build this, but it seems like a simple change that should work.
This is two commits:
passwdexits with zero exit code indicating success even on error. The variableretwas set up which would enable returning the correct exit code on error, but this wasn’t used. The commit returnsretas was probably originally intended.passwdto receive a-largument that causes it to remove the.termux_authinfofile, in analogy to shadow’s passwd’s -l option. This is accomplished by splittingmaininto two functions,main_set_passwordandmain_remove_password, and adding the functiontermux_remove_passwd, analogous totermux_set_passwd, whichmain_remove_passwordcalls.mainitself is replaced by a simpleswitchto check the arguments.This is technically a breaking change, though it breaks behaviors that I would expect weren’t and shouldn’t’ve been relied upon. Specifically:
passwdother than no arguments and a single-lare rejected, previously they were silently ignored.passwdwhen passed-lchanges.