-
Notifications
You must be signed in to change notification settings - Fork 38.7k
rpc, p2p: add addpermissionflags RPC and allow whitelisting outbound
#26441
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
addwhitelist RPCaddwhitelist RPC
0220d6c to
d14fbaa
Compare
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
d14fbaa to
ea08c79
Compare
0ed1e4d to
cf50266
Compare
luke-jr
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.
I think it would be better to specify as [String "IP" or Number nodeid, [list of permissions], [list of permissions to remove]] or similar.
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.
Concept ACK-ish, in that whitelisting shouldn't require a node restart.
Where I'm not 100% sure (as commented), is that this conceptually feels much more like a persistent setting instead of the ephemeral nature (i.e. effect gone after node restart) that these RPC commands have. Could be a source of confusion?
src/rpc/net.cpp
Outdated
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.
A question rather than a suggestion: should the docs highlight that these permissions do not persist beyond a node reboot? Intuitively, I'd have expected this kind of effect to be persistent, so maybe highlighting that is useful if I'm not the only one?
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.
It's intuitive for me these permissions aren't persistent since there is no way to remove them (thinking about a follow-up adding an option for removal in this RPC), but sounds goods for me to add it in the docs to clarify.
src/net_permissions.cpp
Outdated
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.
Not a big fan of adding extra out-parameters, I think util::Result would be more appropriate here (but also a bit of an overhaul so wouldn't be opposed to doing it in follow-up)
|
I changed it to draft to work on some stuff some reviewers suggested here. Gonna advertise when it ready for review. |
cf50266 to
174d746
Compare
…nitializePermissionFlags
174d746 to
df5d400
Compare
addwhitelist RPCaddpermissionflags RPC
df5d400 to
153e86e
Compare
|
Force-pushed changing the approach and addressing reviews!
|
| static RPCHelpMan addpermissionflags() | ||
| { | ||
| return RPCHelpMan{"addpermissionflags", | ||
| "\nAdd permission flags to the peers using the given IP address (e.g. 1.2.3.4) or\n" |
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.
It took a while before I realized the added permission flags are only applied to new peers (connecting after the rpc command). Not sure if that should have been obvious to me. Maybe change "peers" to "future peers" or something similar?
addpermissionflags RPCaddpermissionflags RPC and allow whitelisting outbound
| // Whitelisted ranges. Any node connecting from these is automatically | ||
| // whitelisted (as well as those connecting to whitelisted binds). | ||
| std::vector<NetWhitelistPermissions> vWhitelistedRange; | ||
| // Whitelisted ranges for outgoing connections. | ||
| std::vector<NetWhitelistPermissions> vWhitelistedRangeOutgoing; | ||
|
|
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 that making the members public is good, it breaks the class encapsulation and allows multiple threads to access/modify the fields without any contention (read/write operations should be guarded).
pablomartin4btc
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.
LarryRuane
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.
I'll review more soon, but here are a couple of instances where changes are not in the correct commits. Each commit should compile (and all tests should pass, but I didn't check that).
hernanmarino
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.
tested ACK. This might help with a couple of functional tests.
|
Converted it to draft to address suggestions and re-build it on top of #27114. |
|
|
||
| // Parse the following format: "perm1,perm2@xxxxxx" | ||
| bool TryParsePermissionFlags(const std::string& str, NetPermissionFlags& output, size_t& readen, bilingual_str& error) | ||
| bool TryParsePermissionFlags(const std::string& str, NetPermissionFlags& output, ConnectionDirection* output_connection_direction, size_t& readen, bilingual_str& error) |
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.
nit: while the other parameter is output_connection_direction, isn't it good idea to change output to output_permission_flags or output_permissions?
| NetPermissionFlags flags; | ||
| size_t offset; | ||
| if (!TryParsePermissionFlags(str, flags, offset, error)) return false; | ||
| if (!TryParsePermissionFlags(str, flags, nullptr, offset, error)) return false; |
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.
nit: Why not using ConnectionDirection::None rather than nullptr to make it more clear?
|
🐙 This pull request conflicts with the target branch and needs rebase. |
|
There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
2 similar comments
|
There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
|
There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
|
Closing it to focus on other approach. |
Built this PR on top of #17167 (that's been closed due to inactivity but had some Concept ACK). So, it allows whitelisting outbound peers.
This PR adds a new RPC
addpermissionflagsto be able to set up permission flags -whitelistthru RPC, so we don't need to restart our node if we want to add new flags.E.g.