What is the recommended way to handle permissions

[navels]

My setup is specifically in the context of docker (ruby:3.3.0-bookworm) but maybe applies more broadly.

We are migrating our development setup from ruby 2.7.8 to 3.3.0 and associated rubygems/bundler versions. We are getting bit by the changes around permissions, where previous versions of bundler would automagically use sudo in order to allow non sudo users to run bundle install to install gems into system directories they wouldn't otherwise be able to write to.

Previously, then, our Dockerfile would start with the base ruby image, install some dependencies, run gem update --system && gem install bundler. A developer would then be able to run bundle install inside the container using their user account, without sudo.

Now that is no longer possible. What is the recommended approach here? I am finding lots of stackoverflow posts and github issues/discussions but no clear guidance on the correct way for a user to bundle install without running into issues.

[martinemde]

Just dropping a quick note before I have a chance to try to reply more fully. Though the rubygems.org Dockerfile might be a bit more complex than you need (we control rubygems version carefully), we do install gems in a way I feel makes sense on ruby 3.3.0.

[navels]

One thing I am observing with our setup is that if I don't run gem update --system then everything is copacetic. There are no permission conflicts later because root hasn't put anything in /usr/local/bundle

[deivid-rodriguez]

I'd also be happy to try give some advice. A sample Dockerfile that reproduces the permission errors would be useful, particular one that shows that difference behavior between running gem update --system or not.

In any case, the advice is normally to, instead of trusting bundler to automatically sudo, configure bundler is use a path that's actually writable by the current user (bundle config path foo), or give the current user permissions to write to the default path.

[deivid-rodriguez]

Closing since there was no further replies.