tons of fixes for terminal/password handling, with the goal of fixing #3853#8184
Merged
keszybz merged 23 commits intosystemd:masterfrom Feb 15, 2018
Merged
tons of fixes for terminal/password handling, with the goal of fixing #3853#8184keszybz merged 23 commits intosystemd:masterfrom
keszybz merged 23 commits intosystemd:masterfrom
Conversation
This modernizes acquire_terminal() in a couple of ways: 1. The three boolean arguments are replaced by a flags parameter, that should be more descriptive in what it does. 2. We now properly handle inotify queue overruns 3. We use _cleanup_ for closing the fds now, to shorten the code quite a bit. Behaviour should not be altered by this.
…hed terminal features Let's forget all relevant terminal features we learnt when we make a console or /dev/null stdin/stdout/stderr. Also, while we are at it, let's drop the various _unlikely_ and _likely_ annotiations around the terminal feature caches. In many cases we call the relevant functions only once in which cases the annotations are likely to do just harm and no good. After all we can't know if the specific code will call us just once or many times...
… not an int We should be careful with these types, and if we do convert between "int" and "ssize_t" we should do so explicitly rather than implicitly. Otherwise this just looks like a bug.
We should rather sleep to much than too little. This otherwise might result in a busy loop, because we slept too little and then recheck again coming to the conclusion we need to go to sleep again, and so on.
It's prettier that way!
We already have the terminal open, hence pass the fd we got to ask_password_tty(), so that it doesn't have to reopen it a second time. This is mostly an optimization, but it has the nice benefit of making us independent from RLIMIT_NOFILE issues and so on, as we don't need to allocate another fd needlessly.
The password prompt used to be highlighted, and that was a good thing. Let's fix things to make the prompt highlighted again. Fixes: systemd#3853
Also, make sure when we run in a container, we don't use the data from /sys at all, but immediately fall back to /dev/console itself.
Let's normalize the behaviour: return a negative errno style error code, and return the resolved string directly as argument.
A couple of fixes: 1. always bzero_explicit() away what we remove from the passphrase buffer. The UTF-8 code assumes the string remains NUL-terminated, and we hence should enforce that. memzero() would do too here, but let's be paranoid after all this is key material. 2. when clearing '*' characters from string, do so counting UTF-8 codepoints properly. We already have code in place to count UTF-8 codepoints when generating '*' characters, hence we should take the same care when clearing them again. 3. Treat NUL on input as an alternative terminator to newline or EOF. 4. When removing characters from the password always also reset the "codepoint" index properly.
2 tasks
keszybz
approved these changes
Feb 15, 2018
Member
keszybz
left a comment
There was a problem hiding this comment.
I won't pretend to fully grok all the terminal handling stuff. Pfff. Looks okey from reading the code, but who knows.
I found some minor typos / wording issues. I think we can merge this as is, and fix those minor issues in a follow up commit.
| * Note: strictly speaking this actually watches for the device being closed, it does *not* really watch | ||
| * whether a tty loses its controlling process. However, unless some rogue process uses TIOCNOTTY on /dev/tty | ||
| * *after* closing its tty otherwise this will not become a problem. As long as the administrator makes sure | ||
| * not configure any service on the same tty as an untrusted user this should not be a problem. (Which he |
| * whether a tty loses its controlling process. However, unless some rogue process uses TIOCNOTTY on /dev/tty | ||
| * *after* closing its tty otherwise this will not become a problem. As long as the administrator makes sure | ||
| * not configure any service on the same tty as an untrusted user this should not be a problem. (Which he | ||
| * probably should not do anyway.) */ |
| if (ioctl(fd, TIOCSCTTY, force) < 0) | ||
| r = -errno; | ||
| r = ioctl(fd, TIOCSCTTY, | ||
| (flags & ~ACQUIRE_TERMINAL_PERMISSIVE) == ACQUIRE_TERMINAL_FORCE) < 0 ? -errno : 0; |
Member
There was a problem hiding this comment.
This formatting is bad. Actually using a temporary variable for this would be nicer.
| r = reset_terminal_fd(tty_fd, true); | ||
| if (r < 0) | ||
| log_warning_errno(r, "Failed to reset terminal, ignoring: %m"); | ||
|
|
| bool colors_enabled(void) { | ||
|
|
||
| /* Returns true if colors are considered supported on our stdout. For that we check $SYSTEMD_COLORS first | ||
| * (which is the explicit way to turn off/on colors). If that didn't work we turn off colors unless we are on a |
| * | ||
| * For that we first check if we explicitly got told to use colors or not, by checking $SYSTEMD_COLORS. If that | ||
| * didn't tell us anything we check whether PID 1 has $TERM set, and if not whether $TERM is set on the kernel | ||
| * command line. If we find $TERM set we assume color if it's not set to "dumb", similar to regular |
| assert(consoles); | ||
| assert(ret); | ||
|
|
||
| /* If we /sys is mounted read-only this means we are running in some kind of container environment. In that |
|
|
||
| k = utf8_encoded_valid_unichar(str); | ||
| if (k < 0) | ||
| return (size_t) -1; |
Member
There was a problem hiding this comment.
Make it ssize_t and return a proper -EINVAL?
| return ((lead - 0xd800) << 10) + (trail - 0xdc00) + 0x10000; | ||
| } | ||
|
|
||
| size_t utf8_n_codepoints(const char *str); |
| if (ttyfd < 0) | ||
| return; | ||
|
|
||
| /* Backspaces back for enough characters to entirely undo printing of the specified string. */ |
Member
There was a problem hiding this comment.
I think the second "back" is redundant.
keszybz
added a commit
that referenced
this pull request
Feb 15, 2018
Trivial merge conflict resolved locally.
keszybz
added a commit
to keszybz/systemd
that referenced
this pull request
Feb 16, 2018
Follow up for review of systemd#8184.
keszybz
added a commit
to keszybz/systemd
that referenced
this pull request
Feb 19, 2018
Follow up for review of systemd#8184.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.