nspcc-dev/neofs-s3-gw

Fork 0

mirror of https://github.com/nspcc-dev/neofs-s3-gw.git synced 2026-03-01 04:29:15 +00:00

Add NeoFS ACL checking #339

New issue

Closed

opened 2025-12-28 17:37:03 +00:00 by sami · 4 comments

sami commented

2025-12-28 17:37:03 +00:00

Owner

Originally created by @KirillovDenis on GitHub (Sep 26, 2022).

There is some issue that allows user bypass ACL rules because of caching object headers.

To solve this we should do some acl checking when we return some info from caches. This also can reduce number of failed request (because of Access denied error) to nodes.

We can start fix access to cached object with individual object cache

TODO

Fix heading cached object without permission
s3-gw-issues 713
...
✍️

Originally created by @KirillovDenis on GitHub (Sep 26, 2022). There is some issue that allows user bypass ACL rules because of caching object headers. To solve this we should do some acl checking when we return some info from caches. This also can reduce number of failed request (because of `Access denied` error) to nodes. We can start fix access to cached object with [individual object cache](https://github.com/nspcc-dev/neofs-s3-gw/blob/be4600988e745eac6e6babe168745aa3836d59ad/api/cache/objects.go) # TODO - [ ] Fix heading cached object without permission - [x] s3-gw-issues 713 ... :writing_hand:

sami

2025-12-28 17:37:03 +00:00

closed this issue
added the
U3

epic
labels

sami commented

2025-12-28 17:37:04 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (Sep 26, 2022):

do some acl checking

seems very (VERY) questionably to me on the gate side. The current problem is that object cache stores responses without auth data (public key), am I right? Seems like caching key along with object address solves the issue. However, this increases resource consumption.

@cthulhu-rider commented on GitHub (Sep 26, 2022): > do some acl checking seems very (VERY) questionably to me on the gate side. The current problem is that object cache stores responses without auth data (public key), am I right? Seems like caching key along with object address solves the issue. However, this increases resource consumption.

sami commented

2025-12-28 17:37:04 +00:00

Author

Owner

@KirillovDenis commented on GitHub (Sep 27, 2022):

Seems like caching key along with object address solves the issue

Actually not. We cannot map one public key to the object in the cache because eACL can contains complex rules that restrict access only for specific keys.

seems very (VERY) questionably to me on the gate side

It's not only because of current cache errors. As I remember we wanted implement s3-compatible checking on s3-gate. It seems now is appropriate time to start doing this.

@KirillovDenis commented on GitHub (Sep 27, 2022): > Seems like caching key along with object address solves the issue Actually not. We cannot map one public key to the object in the cache because eACL can contains complex rules that restrict access only for specific keys. > seems very (VERY) questionably to me on the gate side It's not only because of current cache errors. As I remember we wanted implement s3-compatible checking on s3-gate. It seems now is appropriate time to start doing this.

sami commented

2025-12-28 17:37:04 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (Sep 27, 2022):

I meant we don't care about ACL at all, we just cache (object_address, client_key) pair response from the NeoFS. But maybe I haven't understood the problem correctly.

s3-compatible checking on s3-gate

Oh, if you mean processing S3 entities only w/o touching things like NeoFS container ACL than that seems good.

@cthulhu-rider commented on GitHub (Sep 27, 2022): I meant we don't care about ACL at all, we just cache (object_address, client_key) pair response from the NeoFS. But maybe I haven't understood the problem correctly. > s3-compatible checking on s3-gate Oh, if you mean processing S3 entities only w/o touching things like NeoFS container ACL than that seems good.

sami commented

2025-12-28 17:37:04 +00:00

Author

Owner

@alexvanin commented on GitHub (Oct 3, 2022):

After some internal discussions with @realloc we've decided to postpone extended ACL checks in gateway. Originally we wanted to use extended ACL tables to decide whether to access data from the storage or not. It has some critical flaws:

S3 gateway can't check rules better than storage node, it is giant field for new bugs and inconsistencies
S3 gateway was not designed to proceed NeoFS rules in the first place
The only rules S3 gateway can parse from extended ACL is a system rules, because they are controlled and interpreted directly by gateway and does not affect storage policy.

To solve access control issue we are going to use access control cache.

This issue is closed until further updates.

@alexvanin commented on GitHub (Oct 3, 2022): After some internal discussions with @realloc we've decided to postpone extended ACL checks in gateway. Originally we wanted to use extended ACL tables to decide whether to access data from the storage or not. It has some critical flaws: - S3 gateway can't check rules better than storage node, it is giant field for new bugs and inconsistencies - S3 gateway was not designed to proceed NeoFS rules in the first place - The only rules S3 gateway can parse from extended ACL is a system rules, because they are controlled and interpreted directly by gateway and does not affect storage policy. To solve access control issue we are going to use access control cache. This issue is closed until further updates.