starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00

[GH-ISSUE #755] [FEATURE REQUEST] Build `rootless` container image #274

New issue

Closed

opened 2026-02-27 08:16:18 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 08:16:18 +03:00

Owner

Originally created by @onedr0p on GitHub (Dec 10, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/755

Motivation

LLDAP cannot not run as nonroot with strict security constraints because it uses gosu and chowns data on start. As a tool that is built for security, best practices should be followed and gosu should be removed in favor of the supported method provided by the Docker runtime.

github.com/lldap/lldap@70d85524db/docker-entrypoint.sh (L24-L26)

The error I get is when I set readOnlyRootFilesystem to true in Kubernetes securityContext:

k logs -n security lldap-6bf866cc88-lnqtv
Defaulted container "main" out of: main, init-db (init)
> Setup permissions..
chown: /app: Read-only file system

Describe the solution you'd like

Remove gosu and support the official method of using the user option in Docker Compose:

user
Optional User and Group ID you want to run the container as. lldap will run using this UID:GID and any files it creates in your /config volume will also be owned by this user and group. The default for this, if not specified, is 1000:1000.

networks:
  lldap:
    name: lldap
    external: true

services:
  recyclarr:
    image: ghcr.io/lldap/lldap
    container_name: lldap
    user: 1000:1000
    networks: [lldap]
    volumes:
      - ./lldap_data:/data
    environment:
      - TZ=America/Santiago

Originally created by @onedr0p on GitHub (Dec 10, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/755 **Motivation** LLDAP cannot not run as nonroot with strict security constraints because it uses gosu and chowns data on start. As a tool that is built for security, best practices should be followed and gosu should be removed in favor of the supported method provided by the Docker runtime. https://github.com/lldap/lldap/blob/70d85524db4d7070f1fda499702bbbd3ec2dd8b5/docker-entrypoint.sh#L24-L26 The error I get is when I set `readOnlyRootFilesystem` to `true` in Kubernetes `securityContext`: ``` k logs -n security lldap-6bf866cc88-lnqtv Defaulted container "main" out of: main, init-db (init) > Setup permissions.. chown: /app: Read-only file system ``` **Describe the solution you'd like** Remove gosu and support the official method of using the `user` option in Docker Compose: > user > Optional User and Group ID you want to run the container as. lldap will run using this UID:GID and any files it creates in your /config volume will also be owned by this user and group. The default for this, if not specified, is 1000:1000. ```yaml networks: lldap: name: lldap external: true services: recyclarr: image: ghcr.io/lldap/lldap container_name: lldap user: 1000:1000 networks: [lldap] volumes: - ./lldap_data:/data environment: - TZ=America/Santiago ```

kerem

2026-02-27 08:16:18 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 08:16:19 +03:00

Author

Owner

@onedr0p commented on GitHub (Dec 10, 2023):

I am willing to PR this change with the supporting docs around it.

@onedr0p commented on GitHub (Dec 10, 2023): I am willing to PR this change with the supporting docs around it.

kerem commented

2026-02-27 08:16:19 +03:00

Author

Owner

@martadinata666 commented on GitHub (Dec 10, 2023):

Initially LLDAP also adopt that conformity, v0.3 *cmiiw. The gosu was used to solve installation on synology, or NAS software alike, essentially when deployed LLDAP got permission error to read/write /data and /app even when specify user: xxxx:xxxx. Tbf I don't use syno, so I don't know how their mounting permission works. If this can be cleared up maybe we can adopt docker method.

@martadinata666 commented on GitHub (Dec 10, 2023): Initially LLDAP also adopt that conformity, v0.3 *cmiiw. The `gosu` was used to solve installation on synology, or NAS software alike, essentially when deployed LLDAP got permission error to read/write `/data` and `/app` even when specify `user: xxxx:xxxx`. Tbf I don't use syno, so I don't know how their mounting permission works. If this can be cleared up maybe we can adopt docker method.

kerem commented

2026-02-27 08:16:19 +03:00

Author

Owner

@onedr0p commented on GitHub (Dec 10, 2023):

This would be a breaking change for some users of the project, because they will need to adopt the official way to handle it. It's been years since I ran Syno but IIRC it is just docker-compose. So as long as the user sets that user var and chowns the data folder themselves prior to deploying lldap or uses the uid:gid that already is set on the lldap data folder they should not have an issue.

@onedr0p commented on GitHub (Dec 10, 2023): This would be a breaking change for some users of the project, because they will need to adopt the official way to handle it. It's been years since I ran Syno but IIRC it is just docker-compose. So as long as the user sets that `user` var and `chown`s the data folder themselves prior to deploying lldap or uses the `uid:gid` that already is set on the lldap data folder they should not have an issue.

kerem commented

2026-02-27 08:16:19 +03:00

Author

Owner

@nitnelave commented on GitHub (Dec 10, 2023):

The current image uses gosu in order to solve common permission problems
that made installation harder. I'd like to keep it that way, in part
because of compatibility reasons.

However, I'm entirely open to also having a non root image that you can opt
into, with a sightly different entry point. We can automate it in GitHub
actions to have both images kept up to date.

Would that work for you?

On Sun, 10 Dec 2023, 16:21 Devin Buhl, @.***> wrote:

This would be a breaking change for some users of the project, because
they will need to adopt the official way to handle it. It's been years
since I ran Syno but IIRC it is just docker-compose. So as long as the user
sets that user var and chowns the data folder themselves prior to
deploying lldap or uses the uid:gid that already is set on the lldap
folder they should not have an issue.

—
Reply to this email directly, view it on GitHub
https://github.com/lldap/lldap/issues/755#issuecomment-1848994473, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWNA7XGPFGNXJVFDTJTYIXHN3AVCNFSM6AAAAABAOTZXB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYHE4TINBXGM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@nitnelave commented on GitHub (Dec 10, 2023): The current image uses gosu in order to solve common permission problems that made installation harder. I'd like to keep it that way, in part because of compatibility reasons. However, I'm entirely open to also having a non root image that you can opt into, with a sightly different entry point. We can automate it in GitHub actions to have both images kept up to date. Would that work for you? On Sun, 10 Dec 2023, 16:21 Devin Buhl, ***@***.***> wrote: > This would be a breaking change for some users of the project, because > they will need to adopt the official way to handle it. It's been years > since I ran Syno but IIRC it is just docker-compose. So as long as the user > sets that user var and chowns the data folder themselves prior to > deploying lldap or uses the uid:gid that already is set on the lldap > folder they should not have an issue. > > — > Reply to this email directly, view it on GitHub > <https://github.com/lldap/lldap/issues/755#issuecomment-1848994473>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWNA7XGPFGNXJVFDTJTYIXHN3AVCNFSM6AAAAABAOTZXB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYHE4TINBXGM> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

kerem commented

2026-02-27 08:16:19 +03:00

Author

Owner

@onedr0p commented on GitHub (Dec 10, 2023):

That works, the way I've seen other projects do that is by adding a -non-root suffix to the tag. I have updated the issue title.

@onedr0p commented on GitHub (Dec 10, 2023): That works, the way I've seen other projects do that is by adding a `-non-root` suffix to the tag. I have updated the issue title.

kerem commented

2026-02-27 08:16:19 +03:00

Author

Owner

@martadinata666 commented on GitHub (Dec 28, 2023):

Added support with rootless image. It expected run with user 1000 by default, override with user: xxxx:yyyy.

But I'm not really sure how it interacts with this The error I get is when I set readOnlyRootFilesystem to true in Kubernetes securityContext:

@martadinata666 commented on GitHub (Dec 28, 2023): Added support with `rootless` image. It expected run with user 1000 by default, override with `user: xxxx:yyyy`. But I'm not really sure how it interacts with this `The error I get is when I set readOnlyRootFilesystem to true in Kubernetes securityContext:`

kerem commented

2026-02-27 08:16:19 +03:00

Author

Owner

@nitnelave commented on GitHub (Dec 28, 2023):

The new entrypoint doesn't try to chown/copy anything if the config file already exists, so it should be compatible with a read-only FS

@nitnelave commented on GitHub (Dec 28, 2023): The new entrypoint doesn't try to chown/copy anything if the config file already exists, so it should be compatible with a read-only FS