Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permissions on /tmp when launching with sbtuser #258

Open
dcunited001 opened this issue Aug 17, 2023 · 9 comments
Open

Permissions on /tmp when launching with sbtuser #258

dcunited001 opened this issue Aug 17, 2023 · 9 comments

Comments

@dcunited001
Copy link

dcunited001 commented Aug 17, 2023

I've rebuilt the image with build args USER_ID and GROUP_ID and I think I'm getting an error related to #219

I'm launching the container via emacs and then launching SBT via tramp (see: hvesalai/emacs-sbt-mode#170). However, I'm getting the error no matter how I launch the containers. When connect with the root user, it goes away, but then I end up creating extraneous root-owned files in the project.

My current docker compose:

services:
  scala:
    build:
      context: .
      dockerfile: docker-sbt.Dockerfile
      args:
        USER_ID: 1000 #${USER_ID:-1000}
        GROUP_ID: 1000 #${GROUP_ID:-1000}
        #SCALA_VERSION: ${SCALA_VERSION:-2.13.10}
        #SBT_VERSION: ${SBT_VERSION:-1.6.2}
        #BASE_IMAGE_TAG: ${BASE_IMAGE_TAG:-11.0.16.1_1-jdk}
        #FROM eclipse-temurin:${BASE_IMAGE_TAG}
    container_name: courserascala1
    hostname: courserascala1
    image: dc/sbtscala
    user: sbtuser
    working_dir: /home/sbtuser/project
    command: /bin/bash 
    # command: sbt # still happens
    stdin_open: true
    tty: true
    volumes:
      - type: bind
        source: recfun
        target: /home/sbtuser/project

The specific error

java.io.IOException: Permission denied
	at java.base/java.io.UnixFileSystem.createFileExclusively(Native Method)
	at java.base/java.io.File.createTempFile(File.java:2129)
	at sbt.StandardMain$.$anonfun$initialGlobalLogging$1(Main.scala:242)
	at sbt.internal.io.Retry$.apply(Retry.scala:46)
	at sbt.internal.io.Retry$.apply(Retry.scala:28)
	at sbt.internal.io.Retry$.apply(Retry.scala:23)
	at sbt.StandardMain$.createTemp$1(Main.scala:240)
	at sbt.StandardMain$.$anonfun$initialGlobalLogging$3(Main.scala:246)
	at sbt.internal.util.GlobalLogBacking$.apply(GlobalLogging.scala:61)
	at sbt.internal.util.GlobalLogging$.initial(GlobalLogging.scala:88)
	at sbt.StandardMain$.initialGlobalLogging(Main.scala:247)
	at sbt.StandardMain$.initialGlobalLogging(Main.scala:250)
	at sbt.StandardMain$.initialState(Main.scala:280)
	at sbt.xMain$.$anonfun$run$11(Main.scala:126)
	at scala.util.DynamicVariable.withValue(DynamicVariable.scala:62)
	at scala.Console$.withIn(Console.scala:230)
	at sbt.internal.util.Terminal$.withIn(Terminal.scala:578)
	at sbt.internal.util.Terminal$.$anonfun$withStreams$1(Terminal.scala:358)
	at scala.util.DynamicVariable.withValue(DynamicVariable.scala:62)
	at scala.Console$.withOut(Console.scala:167)
	at sbt.internal.util.Terminal$.$anonfun$withOut$2(Terminal.scala:568)
	at scala.util.DynamicVariable.withValue(DynamicVariable.scala:62)
	at scala.Console$.withErr(Console.scala:196)
	at sbt.internal.util.Terminal$.withOut(Terminal.scala:568)
	at sbt.internal.util.Terminal$.withStreams(Terminal.scala:358)
	at sbt.xMain$.withStreams$1(Main.scala:87)
	at sbt.xMain$.run(Main.scala:121)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at sbt.internal.XMainConfiguration.run(XMainConfiguration.java:57)
	at sbt.xMain.run(Main.scala:46)
	at xsbt.boot.Launch$.$anonfun$run$1(Launch.scala:149)
	at xsbt.boot.Launch$.withContextLoader(Launch.scala:176)
	at xsbt.boot.Launch$.run(Launch.scala:149)
	at xsbt.boot.Launch$.$anonfun$apply$1(Launch.scala:44)
	at xsbt.boot.Launch$.launch(Launch.scala:159)
	at xsbt.boot.Launch$.apply(Launch.scala:44)
	at xsbt.boot.Launch$.apply(Launch.scala:21)
	at xsbt.boot.Boot$.runImpl(Boot.scala:78)
	at xsbt.boot.Boot$.run(Boot.scala:73)
	at xsbt.boot.Boot$.main(Boot.scala:21)
	at xsbt.boot.Boot.main(Boot.scala)
[error] [launcher] error during sbt launcher: java.io.IOException: Permission denied
@francisdb
Copy link
Collaborator

As a workaround you could try this:
sbt/sbt#6979 (comment)

@francisdb
Copy link
Collaborator

francisdb commented Aug 18, 2023

what does this yield for your image?

~ docker run -it --rm sbtscala/scala-sbt:eclipse-temurin-jammy-19.0.1_10_1.9.1_3.3.0 ls -al /tmp
total 16
drwxrwxrwt 1 root    root    4096 Jul 10 01:31 .
drwxr-xr-x 1 root    root    4096 Aug 18 07:23 ..
drwxr-xr-x 1 root    root    4096 Dec  9  2022 hsperfdata_root
drwxr-xr-x 2 sbtuser sbtuser 4096 Jul 10 01:31 hsperfdata_sbtuser

(I do wonder why that hsperfdata is not deleted)

@dcunited001
Copy link
Author

After starting the container, I get the same output.

I changed the compose to run as root, then I connect later with tramp:

# user: sbtuser
working_dir: /home/sbtuser/project
# command: sbt
command: /bin/bash

After starting sbt in the project, this is what I'm seeing.

root@courserascala1: /home/sbtuser/project^Groot@courserascala1:/home/sbtuser/project# ls -al /tmp/
ls -al /tmp/
total 56
drwxrwxrwt 1 root    root    4096 Aug 27 01:44 .
drwxr-xr-x 1 root    root    4096 Aug 21 21:00 ..
drwx------ 2 root    root    4096 Aug 21 21:25 bsp-launcher10237998301059017850
drwx------ 2 root    root    4096 Aug 21 21:07 bsp-launcher12964533278366146959
drwx------ 2 root    root    4096 Aug 21 21:25 bsp-launcher1644280177820997293
drwx------ 2 root    root    4096 Aug 21 21:25 bsp-launcher5676528235999640185
drwx------ 2 root    root    4096 Aug 21 21:07 bsp-launcher5909924657242283414
drwx------ 2 root    root    4096 Aug 21 21:07 bsp-launcher8821835483790052871
drwxr-xr-x 1 root    root    4096 Aug 27 01:44 hsperfdata_root
drwxr-xr-x 2 sbtuser sbtuser 4096 Aug 18 09:01 hsperfdata_sbtuser
drwxr-xr-x 2 root    root    4096 Aug 21 21:25 jna-3506402
drwxr-xr-x 3 root    root    4096 Aug 27 01:44 .sbt
drwxr-xr-x 3 root    root    4096 Aug 27 01:44 .sbt82f575fe
prw-r--r-- 1 root    root       0 Aug 21 21:07 tramp.he1WlG
prw-r--r-- 1 root    root       0 Aug 21 21:25 tramp.Val83A
root@courserascala1: /home/sbtuser/project^Groot@courserascala1:/home/sbtuser/project#

I've been pulled in a lot of directions lately, so I may need to wait on the
coursera class. I dabbled in the class in 2014 and Scala seems pretty cool. Now
I'm interested in running some code on Spark, so I may come back to it.

Is there anything obvious I can fix with the container? There are a few hacky
ways to fix it if I chown temp or something.

Thanks

@francisdb
Copy link
Collaborator

To be honest I have no idea what this issue is, a minimal reproducer without compose (steps to take) would be welcome

@schlawg
Copy link

schlawg commented Oct 26, 2023

Not sure if this is related, but I have trouble launching any of the recent docker images with --user=<someone_other_than_root>. It used to work under eclipse-temurin-focal-17.0.5_8_1.8.2_3.2.2, you could -u=1000 via argument or specify a user in compose and it would just work.

Maybe I'm doing something wrong but I just get exceptions trying to create the /.sbt directory when launching sbt, regardless of -w or working_dir

Maybe restricted users without root and sudo aren't that common anymore, but it's an issue for me.

@schlawg
Copy link

schlawg commented Oct 27, 2023

I'm not sure about the OP's issue, but here you can reproduce mine:

docker run --rm -u=1000 -it sbtscala/scala-sbt:eclipse-temurin-jammy-21_35_1.9.7_3.3.1 sbt

Docker version 24.0.6, build ed223bc (daemon)

@schlawg
Copy link

schlawg commented Oct 31, 2023

The images can be run under a restricted user with some aggressive volume mapping.

    volumes:
      - $HOME/.ivy2:/.ivy2
      - $HOME/.sbt:/.sbt
      - $HOME/.cache:/.cache
      - $HOME/root:/root

for compose and for regular docker:

-v=$HOME/.ivy2:/.ivy2 -v=$HOME/.sbt:/.sbt -v=$HOME/.cache:/.cache -v=$HOME/root:/root

@Carbrex
Copy link
Contributor

Carbrex commented Mar 28, 2024

I'm not sure about the OP's issue, but here you can reproduce mine:

docker run --rm -u=1000 -it sbtscala/scala-sbt:eclipse-temurin-jammy-21_35_1.9.7_3.3.1 sbt

Docker version 24.0.6, build ed223bc (daemon)

If you want to run this under a non-root user

docker run --rm -u=1001 -it sbtscala/scala-sbt:eclipse-temurin-jammy-21_35_1.9.7_3.3.1 sbt

will work fine.

## Users wanting to use this container as non-root should combine the two following arguments
## -u sbtuser
## -w /home/sbtuser

@Carbrex
Copy link
Contributor

Carbrex commented Jun 27, 2024

I'm not sure about the OP's issue, but here you can reproduce mine:

docker run --rm -u=1000 -it sbtscala/scala-sbt:eclipse-temurin-jammy-21_35_1.9.7_3.3.1 sbt

Docker version 24.0.6, build ed223bc (daemon)

Here's a workaround we are using so that users having id other than 1001(sbtuser's id) don't get error while using sbt.
https://github.com/lichess-org/lila-docker/blob/868d6dcf240a3b3394dfa40e420435c28af8a4a9/docker/sbt.Dockerfile


And in regard of this

Permissions on /tmp when launching with sbtuser

I don't see any error when I mkdir dir in /tmp dir as sbtuser, the /tmp directory has drwxrwxrwt these permissions allowing all users to write in that directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants