#16 Fixed gosu call if container is started as defined user

[sgflt]

• f.e. if compose.yml contains user: 1000:1000, it is not possible to switch user

• we can switch only from root user

Description

Improved handling of user id in entrypoint.sh.

Now it tries to switch user only if root is executing startup script.

Related Issues

Fixed #16

Acceptance Criteria

• New features or enhancements are fully implemented and do not break existing functionality, so that they can be released at any time without requiring additional work
• Automated unit and/or acceptance tests are included to ensure that changes work as expected and to reduce repetitive manual work
• Documentation has been / will be updated, especially as it relates to new configuration options or potentially disruptive changes

---

Contribution Agreement

When contributing code or other intellectual property for the first time, we ask that you read and agree to the following so that we can safely use it in all of our projects without risking unexpected legal disputes or having to repeatedly ask for permission:

• I grant PhotoPrism a non-exclusive, perpetual, irrevocable, worldwide, fully-paid, royalty-free, and transferable right to use, copy, modify, merge, publish, distribute, sublicense and/or sell my Contributions without any restrictions. This includes a non-exclusive, perpetual, irrevocable, worldwide, fully-paid, royalty-free, and transferable patent license to use, offer for sale, sell, import, export, and otherwise transfer or make available my Contributions. PhotoPrism may, in its sole discretion, apply any license to my Contributions that it deems appropriate for the particular purpose, including other open source, copyleft, and proprietary licenses. PhotoPrism may assign this Agreement and all of its rights, obligations and licenses hereunder.
• I confirm that I am the sole author of this Contribution and am legally authorized to grant the above licenses and waivers with respect to this Contribution and any other of my Contributions. If your Contributions were created in the course of your employment with your former or current employer, you represent that this employer has authorized you to make your Contributions on its behalf or has waived all rights, claims, or interests in your Contributions.

PhotoPrism UG ("PhotoPrism", "we" or "us") hereby confirms to you that, to the fullest extent permitted by applicable law, this Contribution is provided "AS IS" WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OR CONDITIONS OF NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. You have no obligation to provide support, maintenance, or other services for your Contribution.

This agreement is solely for our protection and that of our users. It does not grant us exclusive rights to your code.

Thank you very much! 🌈💎✨

[lastzero]

Thank you very much! Sorry for not getting back to you earlier.

From what I remember of discussions with users/contributors, there could be a problem when using gosu with processes that need to access hardware acceleration devices because, under certain conditions, it might not pass existing group memberships to the new process it starts. For this reason, we stopped using gosu in our main repository.

You should find more information on this in the comments of this pull request:

• Docker: Switch from gosu to setpriv in entrypoint.sh photoprism#2730

[lastzero]

I just checked the changes and noticed that we might already be using gosu for the vision container image? If so, have you noticed any issues with hardware acceleration? Since your changes only seem to add fixes, I will then go ahead and merge this after your confirmation :)

[sgflt]

I cannot confirm GPU acceleration as I do not have sufficient hardware.

[sgflt]

Now I have. I will try gosu within a few days.

[sgflt]

I did quick test. In general gosu does not seem to be problem. But I have had to update torch to get RTX 5080 working.

After update caption with kosmos-2 returns just initial prompt and vit-gpt2 loading fails completely with error:

Make sure that a _reorder_cache function is correctly implemented in transformers.models.gpt2.modeling_gpt2 to enable beam search for class 'transformers.models.gpt2.modeling_gpt2.GPT2LMHeadModel'

At least GPU is visible and hypotheticaly accessible.

nvidia-smi -l

|    0   N/A  N/A          118703      C   /app/venv/bin/python3                  1444MiB |

[lastzero]

Thanks for testing it! I guess the Nvidia container toolkit helps to work around this (potential) issue. From what I remember, it was mainly a problem with Intel hardware/drivers. Either way, it seems the vision service code needs more work... 🔧