CommunitySolidServer: Authentication with on-disk config creates locks with too long filename
Going further on my problems yesterday in #1012 I used the library that @joachimvh mentioned. Authenticating worked perfectly when I used the in-memory configuration, but today I have run the server with the on-disk config (so -c file.json). Then, when authenticating, I get redirected to my server which prints the following message:
Error: ENAMETOOLONG: name too long, lstat '/root/data/.internal/locks/aHR0cHM6Ly9wb2QuZ2VlbnMuY2xvdWQvLmludGVybmFsL2lkcC9hZGFwdGVyL1EyeHBaVzUwTDJoMGRIQnpKVE5CSlRKR0pUSkdjbUYzTG1kcGRHaDFZblZ6WlhKamIyNTBaVzUwTG1OdmJTVXlSbWx1Y25Wd2RDVXlSbk52Ykdsa0xXTnNhV1Z1ZEMxaGRYUm9iaTFxY3lVeVJtMWhhVzRsTWtad1lXTnJZV2RsY3lVeVJtSnliM2R6WlhJbE1rWmxlR0Z0Y0d4bGN5VXlSbk5wYm1kc1pTVXlSbUoxYm1Sc1pTVXlSbU5zYVdWdWRDMWhjSEF0Y0hKdlptbHNaUzUwZEd3bE1qTmhjSEE9LmNvdW50'
Seems like the server tries to create a lock with a name that is too long for the filesystem?
(the given lock name is > 300 bytes while the max linux file name length is 255 bytes, so there should probably be a check here)
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 15 (13 by maintainers)
Partially fixed in #1305. Keeping this open until there is a complete fix.
These are URLs generated by the
GreedyReadWriteLockerto keep track of how many locks are active on a given resource so this is not impacted by the locker change. And while we might be able to fix it there, we want a general solution that covers all potential cases.The
EncodingPathStorageis where we convert to base64 so would make sense there. Or perhaps theJsonResourceStoragesince that is where actual URLs are generated by concatenating, depending on the solution. Not all storages use the expiring so not the expiring one.In theory I would just change the base64 encoding that we have in the
EncodingPathStorageto something else that generates a fixed/max length string, potentially with a configurable max length. The problem is that doing this would break data of previous CSS versions when doing an upgrade. So before this solution could be merged we would need some sort of automated solution that migrates data when a previous version is detected. This is why we have theModuleVersionVerifier: https://github.com/CommunitySolidServer/CommunitySolidServer/blob/63060901144c3c8c45704195268face139534e53/src/init/ModuleVersionVerifier.ts#L8-L14 #1267 is a related issue.Now in practice, we could introduce a (potentially temporary, until we have the above) solution that only triggers on URLs that would be too long in the first place anyway. This way we don’t break previous versions since they couldn’t have such resources anyway. This solution would make more sense in the
JsonResourceStoragesince that class knows the full URL.Hashing these identifiers would need to be applied in
ExpiringAdapterFactory.ts(keyForandgrantKeyForfunctions), correct?I would only use the hash when the identifier exceeds 255 characters, and store a mapping of the hash to the identifier for debugging purposes. Maybe the character length threshold and whether to maintain this mapping should be made configurable?