-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
VAULT-12798 Correct removal behaviour when JWT is symlink #18863
Conversation
@@ -61,7 +60,7 @@ func GetTestJWT(t *testing.T) (string, *ecdsa.PrivateKey) { | |||
} | |||
|
|||
func readToken(fileName string) (*logical.HTTPWrapInfo, error) { | |||
b, err := ioutil.ReadFile(fileName) | |||
b, err := os.ReadFile(fileName) |
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.
ioutil.ReadFile
is deprecated.
@@ -83,16 +104,24 @@ func testJWTEndToEnd(t *testing.T, ahWrapping bool) { | |||
|
|||
// We close these right away because we're just basically testing | |||
// permissions and finding a usable file name | |||
inf, err := ioutil.TempFile("", "auth.jwt.test.") | |||
inf, err := os.CreateTemp("", "auth.jwt.test.") |
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.
❓ If we used t.TempDir()
in the paths (dir
), would that allow us to drop the close/cleanup lines?
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 wouldn't - we'd still need to check if the file exists etc and clean it up once we're done with it
📄 Content ChecksUpdated: Wed, 08 Mar 2023 20:12:52 GMT Found 2 error(s)
|
Position | Description | Rule |
---|---|---|
9:65-10:24 |
Unexpected product-relative link: /docs/auth/jwt . Ensure that relative links are fully-qualified Developer paths: /{productSlug}/docs/auth/jwt |
ensure-valid-link-format |
30:6-30:63 |
Unexpected product-relative link: /docs/concepts/duration-format . Ensure that relative links are fully-qualified Developer paths: /{productSlug}/docs/concepts/duration-format |
ensure-valid-link-format |
1 similar comment
📄 Content ChecksUpdated: Wed, 08 Mar 2023 20:12:52 GMT Found 2 error(s)
|
Position | Description | Rule |
---|---|---|
9:65-10:24 |
Unexpected product-relative link: /docs/auth/jwt . Ensure that relative links are fully-qualified Developer paths: /{productSlug}/docs/auth/jwt |
ensure-valid-link-format |
30:6-30:63 |
Unexpected product-relative link: /docs/concepts/duration-format . Ensure that relative links are fully-qualified Developer paths: /{productSlug}/docs/concepts/duration-format |
ensure-valid-link-format |
Updated following discussion on Slack: now requires Sorry this took a while to update, I had lots of other priorities and this one didn't seem like a good plate to spin. |
@@ -18,3 +18,13 @@ method](/docs/auth/jwt). | |||
- `remove_jwt_after_reading` `(bool: optional, defaults to true)` - | |||
This can be set to `false` to disable the default behavior of removing the | |||
JWT after it's been read. | |||
|
|||
- `remove_jwt_follows_symlinks` `(bool: optional, defaults to 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.
I think this is ok. That said, my intuition expected that with this and remove_jwt_after_reading set to true, both the symlink (and any intervening symlinks) as well as the ultimate JWT file referenced would be deleted. An alternative to consider: leave remote_jwt_after_reading behaviour unchanged from prior to PR, i.e. it always only affects the filename referenced in the config, be it file or symlink, and make the new config option control whether or not the symlink target gets deleted.
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.
How about an alternative approach:
We rename remove_jwt_follows_symlinks
to remove_jwt_behavior
, a string with options symlink
and jwt
- it hopefully disambiguates the behaviour, as well as keeps the door open to support a both
, in the future?
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 guess this could also be over-engineering the solution, too, as realistically I think the majority of customers won't want both (and the majority, in my intuition, will only want the jwt
behaviour).
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.
Yeah, maybe we should just stick with what you've got, we've already spent a long time on what I believe to be a niche feature.
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.
Yeah - I agree that this is fairly niche. Thanks for the review, though, and thanks for sticking through with this!
* VAULT-12798 testing for jwt symlinks * VAULT-12798 Add testing of jwt removal * VAULT-12798 Update docs for clarity * VAULT-12798 Small change, and changelog * VAULT-12798 Lstat -> Stat * VAULT-12798 remove forgotten comment * VAULT-12798 small refactor, add new config item * VAULT-12798 Require opt-in config for following symlinks for JWT deletion * VAULT-12798 change changelog
The current behaviour was:
remove_jwt_after_reading
is set to true)In other words, it followed the symlink correctly for reading, but incorrectly for deleting.
I've added a new option,
remove_jwt_follows_symlinks
, that will change this behaviour when set to delete the JWT, instead of the symlink, when removing the JWT.