Uplink CLI generate S3 --writeonly

Developer Discussions troubleshooting
1

I generate an access grant for my personal machine with all permissions (RWLD). I am trying to create a short term access credential for S3 compatibility.

When I run this command, I receive a “Error: permission is empty”.
uplink share --writeonly --register sj://[bucket_name]/[folder]

However, when I run, everything works as expected.
uplink share --readonly=true --register sj://[bucket_name]/[folder]

What am I doing wrong? Also, is this command available in the Python bindings? I couldn’t figure out how to generate the S3 access in the Python bindings.

2

Update:

When I run the following, the command runs, but the permissions are all disallowed. I am expecting that Upload permissions to be active.

uplink share --writeonly --not-after +1h --register sj://[bucket]/[folder]

Sharing access to satellite 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S@us1.storj.io:7777
=========== ACCESS RESTRICTIONS ==========================================================
Download : Disallowed
Upload : Disallowed
Lists : Disallowed
Deletes : Disallowed
NotBefore : No restriction
NotAfter : 2021-11-17 17:53:21

3

Regarding Python bindings, our dev has confirmed that they have the functionality that uplink-c exposed in 1.2.2 - so we do not expect S3 functions to be available.

4

I’d like to make a product feature request for this. Could it please get prioritized? It would save me a lot of workarounds to have that feature.

If I don’t have that feature, I would need to have my code call into bash to run the Storj CLI directly and issue tokens. From there I would need to parse the response back in my code. Lots of room for error.

Is there any feedback on my core issue of the access grant permissions?

5

You can make a feature request here: DCS feature requests - voting - Storj Community Forum (official), however the python binding is a third party repo, it depends on their maintainers. So maybe better to make an issue in the Issues · storj-thirdparty/uplink-python · GitHub

I would suggest not to use the s3 protocol where possible. It has limitations mentioned here: Programmatic Granting of new Access keys - #2 by Alexey

For grant permissions - you need to specify

uplink share --readonly=false --writeonly --not-after +1h --register sj://[bucket]/[folder]

I know it feels counter-intuitive, so I made an internal ticket a while ago. This problem should be solved in the uplinkng tool (it’s expected to be merged to uplink when all features will mature), see [Tech Preview] Uplinkng (new enhanced uplink cli), Changelog v1.42.4, Release preparation v1.43

The explanation of such a behavior - the uplink share command generates read-only grants by default, thus specifying the --writeonly option will extends the default --readonly=true option with the --writeonly=true option, thus by binary logic it results to no permissions at all. So you need to disable the read-only flag and enable write-only flag. Please, note - it will produce:

=========== ACCESS RESTRICTIONS ==========================================================
Download  : Disallowed
Upload    : Allowed
Lists     : Disallowed
Deletes   : Allowed
NotBefore : No restriction
NotAfter  : 2021-11-18 12:08:59

So, if you want to disable deletes or enable downloads - you need to explicitly specify that.

7

Just some more technical details: Generate S3 access with an existing grant is easy, it’s just an HTTP call to the authservice.

Creating a new grant with restricting an existing one is slightly more complex, the existing api key should be parsed, and more restriction should be added.

Check this diagrams for more details:

https://raw.githubusercontent.com/storj/illustrated/main/docs/secrets.svg

https://raw.githubusercontent.com/storj/illustrated/main/docs/macaroon.svg

I agree with the feature request, it would be great to include. But in case you would like to implement it your own, just let me know. I can find the exact details of parsing the grant/macaroon… The only tricky part is the marshall/unmarshall IMHO, after that the signatures are based on standard APIs…

8

I don’t plan on implementing it myself. Unfortunately, I have a growing list of developer workarounds in Storj I have to implement already.

While I wouldn’t mind skipping the S3 altogether, the Storj Swift bindings don’t work for iOS (Ticket). I used the AWSS3 client library because it has a good tutorials and integration for things like upload status and pausing. Also S3 gives me some degree of portability in case there are other issues.

1 Like
9

Could you please share it but the iOS ticket?

10

See this note:

11

These Silicon models have a lot of problems everywhere as far as I can see the news…
The Apple is doing their things as usual :upside_down_face:

Thanks for sharing the info!

12

I just need this to work in iOS for my application! Although I am planning to upgrade machines in the next few months to the new MacBook Pro, so support on M1 would be nice to have.

1 Like
13

i am thanksfull to you for this information.

1 Like