Hi, I was browsing Storj documentation and stumbled upon --user $(id -u):$(id -g) \. My docker commands never included it. Was this change communicated anywhere and I just missed it, or did some Storjling silently change it in the documentation?
1 Like
i think its for better security.
basically you can now define a user and group, so that the storagenode cannot access anything outside that user / group permissions.
also might be because some platforms inherently has these kinds sort of requirements.
haven’t really tinkered with the new --user $(id -u):$(id -g) parameter, but it does seem to cause a good deal of people trouble.
its a solid security measure, but i wouldn’t worry about it, unless if you are doing similar changes to other stuff, i doubt it will ever be a requirement.
so long as your storagenode can access its files, it will be fine.
but don’t add it unless if you are sure what you are doing.
you would most likely need to chown, on all the storagenode files…
which can be quite the task in itself, that blobs folder is not fun to do metadata changes on.
It’s for new setups and to who have concerns about security.
For old nodes it can be applied only if you already doesn’t use root permissions to run containers and chowned all data to the current user and group.
That’s not the answer to the question I’ve asked.
As far as I’m aware it hasn’t been communicated, but it’s also not a vital change. So that makes sense.
3 Likes
This is the only discussion I saw on this topic.
So…Let’s say I wanted to update the permissions to be non-root… would changing all the files and directories to u+rw be sufficient? I see some of the files in the top level storage/ directory currently are u+rw,g+r,o+r. But all the blobs are u+rw.
Would just chown -R $(id -u):$(id -g) do the trick? Or would I want to do a slightly more fancy glob and loop? Are the file permissions themselves going to need adjusting, too?
This likely would take many hours to complete, so I want to make sure I don’t royally screw everything up and have to do it multiple times. Or worse, restore back to root permissions.
Thanks!
@CafeLungo
you would need to use chown -R for recursive ( else it won’t apply the changes in all the sub directories)
adjusting the file permissions with chmod is a can of worms, because like you noted, they are not all the same, and for good reasons, like security and such.
and yes chown should do fine, i would recommend shutting down the node while running the chown…
leaving the node running might cause it to create new files which might be owned by root, thus you might end up with trouble later on… so shut it down while you run the chown.
also i would recommend running the chown in a screen, if you are logged in remotely.
its easy to lose track of the process without doing that… if it doesn’t outright cancel it, if you for whatever reason gets disconnected.
1 Like