Comments (12)
Can you post your Dockerfile
?
It looks like you need to temporarily switch to USER root
for that command and then switch back to USER jetty
.
from docker-jetty.
@md5 This looks like it is going to be a common issue. Perhaps we should put some explicit code into the script so that it gives a reasonable warning and explanation that USER needs to be switched back to ROOT. We should then probably warn in the entry point if the USER is not switched back to jetty
from docker-jetty.
@gregw Sure, that sounds good. I think it would also be good to put an example in the documentation.
from docker-jetty.
@md5 actually switching USER frequently is against best practises. Perhaps we'd be better off moving /jetty-start' into
$JETTY_BASE` so it can be written without changing users?
I'll prepare a PR for that....
from docker-jetty.
I'm not sure the advice against switching USER
frequently really applies here. We only switch it once in the Dockerfile
for this image and I think having derived images switch to USER root
to run commands that need root
before going back to USER jetty
isn't too bad. I suppose it could get a little out of hand if you had multiple layers of derived images.
As for whether it's actually a good practice to have jetty.start
owned by jetty
, I would argue that having all files that should not be writable by the jetty
user from the running application owned by root
would be more secure. This would help prevent attackers from gaining a foothold inside a long-running container by modifying files inside it. Using Docker's read-only mode goes one step further.
from docker-jetty.
Aplogies for my terseness in opening this issue. But you got to an understanding of my complaint in spite of that.
For my two cents, I think this is mostly about documentation. An example would cover it. And the README shown at hub.docker.com needs updating. Thanks!
from docker-jetty.
@md5, I'm not sure this is a security issue as anybody that can write to $JETTY_BASE
has complete control of the server anyway as they can replace any jars etc.
The jetty.start
contents is just a preprocessed version of what is in $JETTY_BASE/start.d
and you do not need root
permission to change that, so it is a bit strange that root
is needed to pre-process it. In fact it is a little strange that in order to prevent the need to run the JVM as root
, we require the user to switch to root
to run the JVM and then switch back.
Also currently if the /jetty.start
does not exist, we create a temporary one in $TMPDIR
. This change allows for the 'jetty.start` file to be in the same location regardless, which is a good simplification.
from docker-jetty.
@gregw Sorry I wasn't more clear. I agree that having jetty.start
owned by jetty
doesn't introduce a new security issue. My intent was to bring up the existing issue that you mention about JARs, config files, etc being writable by the web process.
from docker-jetty.
@md5 OK so you are saying that we should make most of $JETTY_BASE write protected from the jetty
user, so that you can only change configuration in a Dockerfile by switching to root
; configuring server; switching back to jetty
. I can see reason in that, but we'd have to do an audit of all the jetty modules to make sure that none of them lazily change configuration on startup (I don't think any do, but I'm not 99% sure, specially with regards to third party modules like hawte).
If users really want that level of security, then I'd be more inclined to provide a script called protect-jetty-base.sh
which could be run after configuration and it would remove write permission from directories and libraries. Thus an attacker would first need to run chmod before replacing any files.
from docker-jetty.
I think any change to the permissions can be handled as a separate PR/issue.
My feeling at this point is that it's actually best handled in documentation, either describing how to run the equivalent of your protect-jetty-base.sh
command (since it can probably be accomplished with find ... -exec
) or by describing the volumes necessary to run with --read-only
(i.e. where user jetty
should actually be able to write).
from docker-jetty.
@md5 is that comment in relation to #81 as it is, or to further changes that have been suggested to protect $JETTY_BASE
. If the later, then I totally agree. I think #81 is a sensible step and means that users need only switch back to root
for non-jetty related configuration.
from docker-jetty.
I think #81 looks OK. I did just noticed an issue that I'll comment about on that PR.
Aside from that, I'm not sure which comment you're asking about.
from docker-jetty.
Related Issues (20)
- Issues with Docker Build with 1.8.0_191 HOT 2
- Provide Jetty images based on openjdk:11-jre-slim HOT 7
- jetty:9-jre8 SSL no longer works, FIN sent in reply to CLIENT_HELLO HOT 7
- jetty user home is not properly set HOT 5
- sqlite (used in sqlite-libs) version 3.26.0-r3 has 2 vulnerabilities HOT 1
- Mail library included in jetty-jre11 is not compatible with JDK11 HOT 11
- Docker image for jetty 10 HOT 3
- TMPDIR /tmp/jetty not used
- Replace sks-keyservers.net HOT 9
- Discontinue building the image based on OpenJDK JRE 7 HOT 1
- Old version 9.4.18 in docker hub HOT 1
- Container exits immediately when using JDWP in JAVA_OPTIONS HOT 4
- Jetty on top of Openjdk-8 JDK version HOT 2
- Add jetty 9 images based on AdoptOpenJDK HOT 1
- Stop supporting deprecated versions of Jetty HOT 5
- Move official docker-jetty project to the jetty project HOT 3
- jetty 9.4.29 released HOT 1
- Empty jetty.start file HOT 5
- start.jar explodes: missing/invalid file modules/alpn-impl/alpn-1.8.0_181.mod HOT 4
- Any plans for jre11 ? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-jetty.