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.
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
improve ssh filter btrbk.sh #511
base: master
Are you sure you want to change the base?
improve ssh filter btrbk.sh #511
Changes from all commits
35a0fd3
5d1abf8
53b3290
2d3e8e2
47fb294
9050329
e510594
4888cc5
7db20c9
0d34d67
a0237fe
5702978
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Nope, some distros still install btrfs-progs to
/{usr,}/sbin
.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.
Hmm that leads me to some more general question:
Right now
ssh_filter_btrbk.sh
tries to be compatible to all kinds of versions.I think this makes things unnecessarily complex and lax (since we need to allow more patters/styles) that are actually used.
Would I get your blessing, if we changed the script, so that it effectively only accepts exactly those commands, from the current version (respectively git commit)?
In many scenarios, people will anyway use the same version of
btrbk
all over their systems.And even if not, they could simply copy the specific one per case and use that.
Since that one can be selected on a per-SSH-key basis, full control would be possible, whilst greatly simplifying the script.
If you'd agree with that, we could make the
PATH
configurable via Makefile, or simply leave it the duty of the distribution maintainer, to override if still using oldsbin
.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.
Oh and also:
I guess most distros will switch to
/usr/bin
, simply becausebtrfs
can be run as a user, too.And we don't really need to care too much on ancient versions of some distros:
Those would anyway still ship the old
ssh_filter_btrbk.sh
, so people could simply use 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.
I hope so too, but these things usually take quite a while to propagate through all distros.
Probably the "correct" way would be not to restrict PATH at all, as this should be done in a layer below (i.e. sshd_config). Note that as some exotic distros like NixOS install executables outside
/usr/bin
.We need to find a good balance between security and convenience here. As long as there are distros out there installing
btrfs
to/sbin/
(notably Gentoo), we need to keep both.This is asking for trouble. Are you proposing something like "try to find out where third-party software (
btrfs
, ...) was installed, and patch a variable according to it" ?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.
@calestyo Fedora 41, which is one of the biggest distros out there and defaults to btrfs as its FS of choice (thus a high percent of users use btrfs) uses
/usr/sbin
forbtrfs
.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.
Hmm seems a pretty strange choice (I'd call it a bug, TBH), as quite some parts of
btrfs
are usable as normal user.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.
See previous comment, I don't think we should contstrain too much here. This just makes the code more complex, and implies that
//
has some special meaning for btrbk, which it does not.A simple check for leading slash might make some sense for crazy users trying to specify relative paths for whatever reason. Even then, the error is just shifted to here, without that check it will fail saying that the path does not match.
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 may not have in btrbk, but it may in principle have in the OS... so a OS could choose to handle
//
not like/
but e.g. like and object identifier.Then all the constraints we set up to make things secure, wouldn't work anymore. Thus I think it's better to simply forbid
//
at all. In practise no one should anyway ever set 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.
Sadly btrbk does exactly this in some cases (which are not uncommon), see fix: 142fa6c
This means we should keep supporting leading
//
, at least before next major release.Unless it really imposes a security risk, but: I don't know of any linux (!) OS where
//
is treated in a special way, but maybe you know better. OS other that linux will not install ssh_filter_btrbk.sh, as btrfs is only available on linux as far as I know.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.
This might break things. This function should normalize the paths exactly the same way as btrbk does: I believe in some versions btrbk printed
//
in some weird situations, this might match your implementation but also might not.I don't think we should sanitize the paths too much, after all it's the user specifying it, I find it convenient to let the user specify whatever he wants here (especially regex).
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.
Wouldn't it be better to fix those places in
btrbk
instead?btrbk
should never issue leading//
, cause that's dangerous depending on the OS.Especially the regexp thingy I find dangerous... it's not documented as that, and easily breaks things. The tool should rather not support all possible weird scenarios, but therefore restrict for 100% sure in all cases for any normal scenario.
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.
This is intentionally set to 255, so that btrbk can distinguish between ssh errors and exit codes from the command called by ssh:
https://github.com/digint/btrbk/blob/v0.32.5/btrbk#L994
see ssh(1):
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.
Uhm? I don't quite understand that. You say you want it to differ between
ssh
andssh_filter_btrbk.sh
errors, but with255
that’s exactly what wouldn’t work, cause then the program returns that on an errror... as wouldssh
.E.g. on an config file 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.
No, I want to differ between
ssh
errors and remote command errors (while regarding errors from ssh_filter_btrbk.sh asssh
errors).I need to know that if e.g.
btrfs receive
fails, this is not due to some failure of ssh/ssh_filter_btrbk.sh, but is a failure of thebtrfs receive
command.