Open thaJeztah opened 4 years ago
@AkihiroSuda @tonistiigi @tiborvass ptal
This isn't really possible as uid/gid is part of the cache. Therefore it can't be different for same mount appearing multiple times. Another issue is that USER
can be username that only makes sense in the relation of /etc/passwd
that probably is not on the mount. Looking that up is slow(and actually not possible as all mounts are prepared independently) and again may be different for different contexts.
@tonistiigi I don't think a lookup is needed. I didn't mean for it to lookup the current image's USER
but that BuildKit should look at the permissions of the target
, so in the example above, the target (mount point) is /mycache
;
/mycache
is an existing directory in the image, stat -c "%u:%g" /mycache
, and mount the cache with uid=1000,gid=1000
/mycache
does not exist in the image, proceed as it does right now; create the mountpoint and mount the cache with uid/gid 0:0
(note that it should not do anything with possibly existing content in the cache; only the ownership of the target directory / mount-point)
Therefore it can't be different for same mount appearing multiple times
Isn't that an existing issue? What is the current behavior if I use the same target with different uid/gid combinations?
RUN --mount=type=cache,target=/mycache,uid=123,gid=123 \
echo "do something"
RUN --mount=type=cache,target=/mycache,uid=456,gid=456 \
echo "do something"
I read it wrong but the issues remain. Both in the sense of multiple mounts colliding and mounts being prepared independently.
Isn't that an existing issue?
Yes, I believe this is the case. That's why it's better for it to be explicit so the user can point set a different id in this case. Actually, it would probably be safer to enforce this by default, so that in the example above the cache would not be shared.
I ran into this today, it is surprising to me that the permissions for the mount don't match the target
path if it already exists. It is also incredible hard to figure out that this is happening. If this behavior is intended there should at least be a warning logged if the permissions of the target
path aren't root
Is there a example of how to get a --mount=type=cache to work with anything other than root. As the recommendation to create containers that run as non-root. The mount option seems to be overwriting the existing permissions with root:root making the usage impossible for non root users. Any progress?
Directly specifying user ID (UID) and group ID (GID) not only simplifies user management but significantly bolsters security by ensuring precise control over access permissions, thereby mitigating the risk of unauthorized access:
FROM maven:3.9.6-eclipse-temurin-17
RUN groupadd -g 998 builder && \
useradd --system --create-home --home-dir /home/builder -u 998 -g builder builder
USER builder
WORKDIR /home/builder
ENV MAVEN_CONFIG /home/builder/.m2
COPY pom.xml .
COPY src src
RUN --mount=type=cache,uid=998,gid=998,target=/home/builder/.m2 \
touch /home/builder/.m2/LOCATE_THIS_FILE_XYZ_1 && \
mvn dependency:go-offline && \
mvn test-compile dependency:copy-dependencies -DoutputDirectory=target/dependency
CMD ls -al /home/builder/target
I hope this addresses the issue at hand. Unfortunately, specifying the UID and GID appears to be mandatory, rather than optional.
When using
RUN --mount=type=cache
, theuid/gid
of the mount defaults to0:0
(root
), even if the mountpoint is an existing directory with different permissions.While it's possible to manually override the
uid/gid
for the mount, I think it would make sense to default to the permissions of the mountpoint (if exists), and otherwise fall back to the current behaviour (root
).Example / reproduction steps: