Skip to content
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

If the notification message length is 0, ignore the message. #4237

Closed
wants to merge 1 commit into from
Closed

If the notification message length is 0, ignore the message. #4237

wants to merge 1 commit into from

Conversation

niedbalski
Copy link
Contributor

If the notification message length is 0, write a warning message and ignore.

Fixes #4234

Signed-off-by: Jorge Niedbalski jnr@metaklass.org

@digitalresistor
Copy link

Related: #4234
Duplicate: #4236

if(n <= 0) {
log_unit_debug(u, "Got a zero-length notification message. Ignoring");
return;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is only called from manager_dispatch_notify_fd(), which you fix below. So an assert is appropriate here, we don't want to check the same condition twice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keszybz out of curiosity, How can you assert that no other function will call this method in a future implementation?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If somebody adds another call site, they have to look at the function and see what the prerequisites for the arguments are. assert serves as the documentation for that.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but the attitude "the caller must ensure they won't trip an assert() in the callee" is exactly what led to the state where any unprivileged user can take down pid1, precisely because manager_dispatch_notify_fd() should have but did not do that. So unless you've some other means of programatically verifying that it can't/won't happen again, you're leaving a time bomb waiting for the next refactoring that occurs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have a point. See #4242.

log_warning("Got zero-length notification message. Ignoring.");
return 0;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The (n == 0) check should be after the (n < 0). We check for error conditions first, and then bad input second.

Also, please don't add an empty line here. Since those are all checks for the same operation, they should be adjacent.

Finally, we don't want to warn here, for a repeateable operation performed by some broken service. A debug level log would be OK.

Fixes #4234

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
@niedbalski
Copy link
Contributor Author

@keszybz addressed your suggestions.

@keszybz keszybz added pid1 good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed labels Sep 28, 2016
@niedbalski
Copy link
Contributor Author

@keszybz the CI errors seems to be unrelated to the change.

Copy link
Contributor

@fbuihuu fbuihuu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The indentation you used are wrong.

keszybz pushed a commit that referenced this pull request Sep 29, 2016
Fixes #4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
@keszybz keszybz removed the good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed label Sep 29, 2016
@keszybz
Copy link
Member

keszybz commented Sep 29, 2016

Applied as 531ac2b with an indentation fix.

@keszybz keszybz closed this Sep 29, 2016
@mbiebl
Copy link
Contributor

mbiebl commented Sep 29, 2016

@keszybz I think we should ask @poettering why zero-size messages were explicitly allowed, see #4234 (comment)

edolstra pushed a commit to NixOS/systemd that referenced this pull request Sep 30, 2016
…4237)

Fixes systemd#4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
(cherry picked from commit 531ac2b)
crawford pushed a commit to crawford/systemd that referenced this pull request Oct 19, 2016
…4237)

Fixes systemd#4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
crawford pushed a commit to crawford/systemd that referenced this pull request Oct 20, 2016
…4237)

Fixes systemd#4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
AnchorCat pushed a commit to AnchorCat/systemd that referenced this pull request May 9, 2017
…4237)

Fixes systemd#4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
(cherry picked from commit 531ac2b)
Werkov pushed a commit to Werkov/systemd that referenced this pull request Jun 22, 2017
…4237)

Fixes systemd#4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
(cherry picked from commit 531ac2b)
xrg pushed a commit to xrg/systemd that referenced this pull request Sep 3, 2017
…4237)

Fixes systemd#4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
whot pushed a commit to whot/systemd that referenced this pull request Oct 10, 2017
…4237)

Fixes systemd#4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>

Cherry-picked from: 531ac2b
Resolves: #1380175
mikhailnov pushed a commit to mikhailnov/systemd that referenced this pull request Aug 16, 2019
…4237)

Fixes systemd#4234.

Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet

7 participants