Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Thanks for using the TrueNAS Community Edition issue tracker! TrueNAS Enterprise users receive direct support for their reports from our support portal.

Issues

Select view

Select search mode

 
1-50 of 77
1 of 77

S3 service access key validation error

Complete

Description

When enabling the S3 service and attempting to input an access key, the validator rejects characters that are valid in AWS S3.

In /usr/local/lib/python3.7/site-packages/middlewared/plugins/s3.py, the following lines are the validation code:

52 @accepts(Dict(
53 's3_update',
54 Str('bindip'),
55 Int('bindport', validators=[Range(min=1, max=65535)]),
56 Int('console_bindport', validators=[Range(min=1, max=65535)]),
57 Str('access_key', validators=[Match("^\w+$", explanation="Should onl
y contain alphanumeric characters")],
58 max_length=20),
59 Str('secret_key', validators=[Match("^\w+$", explanation="Should onl
y contain alphanumeric characters")],
60 max_length=40),

However, this is more restrictive than the actual S3 access keys. AWS provides regex validation code for its key ID and secret keys, which is shown below (Perl compatible):

grep -RP '(?<

[A-Z0-9])' *
grep -RP '(?<

[A-Za-z0-9/+=])' *

In order to match the syntax of the actual S3 service, this validator should be updated.

Others have reported this issue in the forums here.

Problem/Justification

None

Impact

None
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Labels

Impact

Low

Time remaining

0m

Components

Fix versions

Affects versions

Priority

Katalon Platform

Created February 10, 2022 at 3:54 PM
Updated July 6, 2022 at 8:57 PM
Resolved February 25, 2022 at 2:47 PM
Configure

Activity

Show:

Bug Clerk February 25, 2022 at 12:20 AM

Bug Clerk February 21, 2022 at 10:44 PM

John C February 18, 2022 at 2:07 PM
Edited

Requesting this be reopened. This is incorrect regarding the current upstream validation and test cases for both the mc client and the minio server. I suspect there is some confusion between my use of "access key"-- by that I mean the secret key, rather than what is sometimes called the "AccessKeyID".

The linked issue seems to be discussing regex for the AccessKeyID. The actual secret key has no such limitations, and as of the current release the AccessKeyID seems to have no restrictions either.

The current upstream validation can be seen here, starting on line 37, and the only validity check it performs is that min length is 8.

You can also see their config test here which uses a secret key of 'minio1#23', currently also rejected by the TrueNAS S3 service.

testCases := []struct { hostURL string .... } hostURL: "https://minio:minio1#23@localhost:9000", accessKey: "minio", secretKey: "minio1#23",

The upstream minio server uses the same validation:

// IsAccessKeyValid - validate access key for right length. func IsAccessKeyValid(accessKey string) bool { return len(accessKey) >= accessKeyMinLen } // IsSecretKeyValid - validate secret key for right length. func IsSecretKeyValid(secretKey string) bool { return len(secretKey) >= secretKeyMinLen }

Valid S3 access keys are thus a subset of all valid minio secret keys. Merely making TrueNAS S3 compatible would want '[\w+=,.@-]+' as a validator, while the least restrictive minio-compatible validator would simply enforce minimum length 8.

If it is correct to resubmit as a separate bug, I can do so-- not sure on protocol here. Thanks!

Muhammad Rehan February 17, 2022 at 9:15 PM

we use minio for S3 which actually has less restrictive permissions then AWS S3 requirements as can be seen here https://github.com/minio/mc/issues/2298#issuecomment-340722058. I'm closing this as this is desired upstream behaviour..

Bonnie Follweiler February 11, 2022 at 1:49 PM

Thank you .

I have moved this ticket in to our queue to review.

An engineering representative will update with any further questions or details in the near future.