Object exists but inaccessible in Mainnet #1417

New issue

Closed

opened 2025-12-28 17:22:56 +00:00 by sami · 3 comments

sami commented

2025-12-28 17:22:56 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (May 20, 2025).

in full-public Mainnet container

$ neofs-cli container get --cid CeeroywT8ppGE4HGjhpzocJkdb2yu3wD5qCGFTjkw1Cc -r st1.storage.fs.neo.org:8080

container ID: CeeroywT8ppGE4HGjhpzocJkdb2yu3wD5qCGFTjkw1Cc
owner ID: NMecMz4YurGg2nVaFuu7hqP3MbXCdRon1c
basic ACL: fffffff
       RangeHASH    Range      Search     Delete     Put        Head       Get
0 0    1 1 1 1      1 1 1 1    1 1 1 1    1 1 1 1    1 1 1 1    1 1 1 1    1 1 1 1
X F    U S O B      U S O B    U S O B    U S O B    U S O B    U S O B    U S O B
  X-Sticky F-Final U-User S-System O-Others B-Bearer
created: 2021-08-30 13:33:16 +0300 MSK
attributes:
	Timestamp=1630319596
placement policy:
REP 2 IN X
CBF 2
SELECT 2 FROM F AS X
FILTER Deployed EQ NSPCC AS F

there is an object which is stored, but:

 neofs-cli object get --cid CeeroywT8ppGE4HGjhpzocJkdb2yu3wD5qCGFTjkw1Cc --oid Cu6Vyun5WQeEnKuwsGFgPAfqyzuxcVN5aBrV83fbUVTA -r st2.storage.fs.neo.org:8080 -v
Missing wallet in the configuration.
Generating random private key for command processing...
Private key generated successfully. Public key: fd0d740abe058271a316e8212986012bc039f3d12c70c59bf584186c90c783259d5e489cc4142d88d8fd341baef65bdf4fa32318bf712fe9adeba008e3e8db41

TTL: 2
Trying to read session from the file...
File with session token is not provided.
rpc error: init object reading on client: read header: status: code = 2048 message = access to object operation denied: access to operation OBJECT_GET is denied by extended ACL check: can't parse headers: invalid header: invalid session token: missing token lifetime

seems like object was created with session token w/o lifetime field. Currently, such objects are invalid. Seems like this object was stored before this check was added to the PUT handler

NOTE that we should ensure this is the case

Expected Behavior

op goes OK

Current Behavior

no data access

Possible Solution

ignore session token problems in read ops. If SN responds with an object, it was valid at the time of writing. Something may have been tightened, but it should not be retroactive

Regression

guess it was retreivable some time ago, but now it's not. From the other side, it's residue in the system is questionable

Your Environment

Version used:

$ neofs-cli --version
NeoFS CLI
Version: 0.45.2-262-g97bc4ed3-dirty 
GoVersion: go1.23.0

Originally created by @cthulhu-rider on GitHub (May 20, 2025). in full-public Mainnet container ``` $ neofs-cli container get --cid CeeroywT8ppGE4HGjhpzocJkdb2yu3wD5qCGFTjkw1Cc -r st1.storage.fs.neo.org:8080 container ID: CeeroywT8ppGE4HGjhpzocJkdb2yu3wD5qCGFTjkw1Cc owner ID: NMecMz4YurGg2nVaFuu7hqP3MbXCdRon1c basic ACL: fffffff RangeHASH Range Search Delete Put Head Get 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 X F U S O B U S O B U S O B U S O B U S O B U S O B U S O B X-Sticky F-Final U-User S-System O-Others B-Bearer created: 2021-08-30 13:33:16 +0300 MSK attributes: Timestamp=1630319596 placement policy: REP 2 IN X CBF 2 SELECT 2 FROM F AS X FILTER Deployed EQ NSPCC AS F ``` there is an object which is stored, but: ``` neofs-cli object get --cid CeeroywT8ppGE4HGjhpzocJkdb2yu3wD5qCGFTjkw1Cc --oid Cu6Vyun5WQeEnKuwsGFgPAfqyzuxcVN5aBrV83fbUVTA -r st2.storage.fs.neo.org:8080 -v Missing wallet in the configuration. Generating random private key for command processing... Private key generated successfully. Public key: fd0d740abe058271a316e8212986012bc039f3d12c70c59bf584186c90c783259d5e489cc4142d88d8fd341baef65bdf4fa32318bf712fe9adeba008e3e8db41 TTL: 2 Trying to read session from the file... File with session token is not provided. rpc error: init object reading on client: read header: status: code = 2048 message = access to object operation denied: access to operation OBJECT_GET is denied by extended ACL check: can't parse headers: invalid header: invalid session token: missing token lifetime ``` seems like object was created with session token w/o lifetime field. Currently, such objects are invalid. Seems like this object was stored before this check was added to the PUT handler NOTE that we should ensure this is the case ## Expected Behavior op goes OK ## Current Behavior no data access ## Possible Solution ignore session token problems in read ops. If SN responds with an object, it was valid at the time of writing. Something may have been tightened, but it should not be retroactive ## Regression guess it was retreivable some time ago, but now it's not. From the other side, it's residue in the system is questionable ## Your Environment * Version used: ``` $ neofs-cli --version NeoFS CLI Version: 0.45.2-262-g97bc4ed3-dirty GoVersion: go1.23.0 ```

sami

2025-12-28 17:22:56 +00:00

closed this issue
added the
bug

neofs-storage

S4

I4

U1
labels

sami commented

2025-12-28 17:22:56 +00:00

Author

Owner

@roman-khimov commented on GitHub (May 20, 2025):

ignore session token problems in read ops.

It's not just about token problems. When we're GETting a particular OID it corresponds to a particular header, whatever the contents is, if OID is correct wrt header it's OK. Then payload hash is known from the header and can be checked as well.

@roman-khimov commented on GitHub (May 20, 2025): > ignore session token problems in read ops. It's not just about token problems. When we're GETting a particular OID it corresponds to a particular header, whatever the contents is, if OID is correct wrt header it's OK. Then payload hash is known from the header and can be checked as well.

sami commented

2025-12-28 17:22:56 +00:00

Author

Owner

@roman-khimov commented on GitHub (May 20, 2025):

Related to #2228, #2302.

@roman-khimov commented on GitHub (May 20, 2025): Related to #2228, #2302.

sami commented

2025-12-28 17:22:56 +00:00

Author

Owner

@roman-khimov commented on GitHub (May 23, 2025):