-
Notifications
You must be signed in to change notification settings - Fork 37.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
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
@@ -272,6 +272,49 @@ static RPCHelpMan getpeerinfo() | |||
}; | |||
} | |||
|
|||
static RPCHelpMan addwhitelist() |
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.
@@ -104,11 +117,11 @@ bool NetWhitebindPermissions::TryParse(const std::string& str, NetWhitebindPermi | |||
return true; | |||
} | |||
|
|||
bool NetWhitelistPermissions::TryParse(const std::string& str, NetWhitelistPermissions& output, bilingual_str& error) | |||
bool NetWhitelistPermissions::TryParse(const std::string& str, NetWhitelistPermissions& output, ConnectionDirection& output_connection_direction, 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.
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).
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.
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).
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. |
@@ -21,9 +21,10 @@ const std::vector<std::string> NET_PERMISSIONS_DOC{ | |||
namespace { | |||
|
|||
// 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
?
@@ -85,7 +98,7 @@ bool NetWhitebindPermissions::TryParse(const std::string& str, NetWhitebindPermi | |||
{ | |||
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
addpermissionflags
to be able to set up permission flags -whitelist
thru RPC, so we don't need to restart our node if we want to add new flags.E.g.