Metasploit-framework: Docker image from metasploitframework/metasploit-framework : `mkdir': Permission denied @ dir_s_mkdir - /home/msf/.msf4/logs (Errno::EACCES)

Created on 5 Apr 2018 · 9Comments · Source: rapid7/metasploit-framework

Steps to reproduce

How'd you do it?

On a new machine without /home//.msf4/
wget https://raw.githubusercontent.com/rapid7/metasploit-framework/master/docker-compose.yml
sudo docker-compose run --rm --service-ports -e MSF_UID=$(id -u) -e MSF_GID=$(id -g) ms

This section should also tell us any relevant information about the
environment; for example, if an exploit that used to work is failing,
tell us the victim operating system and service versions.

Expected behavior

What should happen?

Metasploit should be able to write into /home/msf/.msf4/

Current behavior

Metasploit fail to write into /home/msf/.msf4/ when the file is shared with /home//.msf4/ (see docker-compose.yml)

core@my_vm01 ~ $ sudo docker-compose run --rm --service-ports -e MSF_UID=$(id -u) -e MSF_GID=$(id -g) ms
Starting core_db_1 ... done
Rails Error: Unable to access log file. Please ensure that /home/msf/.msf4/logs/production.log exists and is writable (ie, make it writable for user and group: chmod 0664 /home/msf/.msf4/logs/production.log). The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
Traceback (most recent call last):ork console...\
    16: from ./msfconsole:49:in `<main>'
    15: from /usr/src/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start'
    14: from /usr/src/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start'
    13: from /usr/src/metasploit-framework/lib/metasploit/framework/command/console.rb:62:in `driver'
    12: from /usr/src/metasploit-framework/lib/metasploit/framework/command/console.rb:62:in `new'
    11: from /usr/src/metasploit-framework/lib/msf/ui/console/driver.rb:74:in `initialize'
    10: from /usr/src/metasploit-framework/lib/msf/base/simple/framework.rb:73:in `create'
     9: from /usr/src/metasploit-framework/lib/msf/base/simple/framework.rb:110:in `simplify'
     8: from /usr/src/metasploit-framework/lib/msf/base/config.rb:209:in `init'
     7: from /usr/src/metasploit-framework/lib/msf/base/config.rb:371:in `init'
     6: from /usr/local/lib/ruby/2.5.0/fileutils.rb:193:in `mkdir_p'
     5: from /usr/local/lib/ruby/2.5.0/fileutils.rb:193:in `each'
     4: from /usr/local/lib/ruby/2.5.0/fileutils.rb:208:in `block in mkdir_p'
     3: from /usr/local/lib/ruby/2.5.0/fileutils.rb:208:in `reverse_each'
     2: from /usr/local/lib/ruby/2.5.0/fileutils.rb:210:in `block (2 levels) in mkdir_p'
     1: from /usr/local/lib/ruby/2.5.0/fileutils.rb:232:in `fu_mkdir'
/usr/local/lib/ruby/2.5.0/fileutils.rb:232:in `mkdir': Permission denied @ dir_s_mkdir - /home/msf/.msf4/logs (Errno::EACCES)

What happens instead?

You might also want to check the last ~1k lines of
/opt/metasploit/apps/pro/engine/config/logs/framework.log or
~/.msf4/logs/framework.log for relevant stack traces

System stuff

Metasploit version

msf5 > version
Framework: 5.0.0-dev
Console  : 5.0.0-dev

I installed Metasploit with:

[ ] Kali package via apt
[ ] Omnibus installer (nightly)
[ ] Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
[ ] Source install (please specify ruby version)
[X] Docker image from https://hub.docker.com/r/metasploitframework/metasploit-framework/

OS

Alpine Linux (See Dockerfile)

I am able to reproduce the issue and CoreOS and Fedora (as guest os)

Stale bug

Source

PierrickV

Most helpful comment

The .msf4 folder in your home directoy is owned by root. Execute a chown -R core:core and all will be working

FireFart on 5 Apr 2018

👍2

All 9 comments

The .msf dir from your home directory is mounted inside the container. The container itself runs under the userid specified with the command line parameters.
What's the userid you are passing to MSF_UID and whats the permissions on your $HOME/.msf4 directory?

FireFart on 5 Apr 2018

On CoreOS

Outside the container :

core@my_vm01 ~/metasploit-framework $ echo "docker-compose run --rm --service-ports -e MSF_UID=$(id -u) -e MSF_GID=$(id -g) ms"
docker-compose run --rm --service-ports -e MSF_UID=500 -e MSF_GID=500 ms

core@my_vm01 ~/metasploit-framework $ ls -lah ~/
total 80K
drwxr-xr-x.  5 core core 4.0K Apr  5 12:12 .
drwxr-xr-x.  3 root root 4.0K Apr  3 05:47 ..
-rw-r--r--.  1 core core    0 Apr  5 10:05 .authorized_keys.d.lock
-rw-------.  1 core core 1.5K Apr  5 12:36 .bash_history
lrwxrwxrwx.  1 core core   33 Apr  3 05:47 .bash_logout -> ../../usr/share/skel/.bash_logout
lrwxrwxrwx.  1 core core   34 Apr  3 05:47 .bash_profile -> ../../usr/share/skel/.bash_profile
lrwxrwxrwx.  1 core core   28 Apr  3 05:47 .bashrc -> ../../usr/share/skel/.bashrc
drwxr-xr-x.  2 root root 4.0K Apr  5 10:10 .msf4
drwx------.  3 core core 4.0K Apr  5 10:05 .ssh
-rw-r--r--.  1 core core  180 Apr  5 10:06 .wget-hsts
-rw-r--r--.  1 core core  428 Apr  5 10:06 docker-compose.yml
drwxr-xr-x. 19 core core 4.0K Apr  5 13:35 metasploit-framework

core@my_vm01 ~/metasploit-framework $ ls -lah ~/.msf4/
total 16K
drwxr-xr-x. 2 root root 4.0K Apr  5 10:10 .
drwxr-xr-x. 5 core core 4.0K Apr  5 12:12 ..

Inside the container (with - $HOME/.msf4:/home/msf/.msf4 commented)

msf5 > echo $MSF_UID
[*] exec: echo $MSF_UID

1000

PierrickV on 5 Apr 2018

I'm able to get it working by using my own image pierrickv/msf

core@my_vm01 ~/metasploit-framework $ cat docker-compose-pierrickv.yml 
version: '3'
services:
  ms:
    #image: metasploitframework/metasploit-framework:latest
    image: pierrickv/msf
    environment:
      DATABASE_URL: postgres://postgres@db:5432/msf
    links:
      - db
    ports:
      - 4444:4444
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - $HOME/.msf4:/root/.msf4
      - /tmp/msf:/data/

  db:
    image: postgres:10-alpine
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  pg_data:
    driver: local

msf > version 
Framework: 4.16.49-dev-
Console  : 4.16.49-dev-

msf > echo $MSF_UID
[*] exec: echo $MSF_UID

500

core@my_vm01 ~ $ ls -lah ~/.msf4/
total 64K
drwxr-xr-x. 8 root root 4.0K Apr  5 13:51 .
drwxr-xr-x. 5 core core 4.0K Apr  5 12:12 ..
drwxr-xr-x. 2 root root 4.0K Apr  5 13:51 local
drwxr-xr-x. 2 root root 4.0K Apr  5 13:51 logos
drwxr-xr-x. 3 root root 4.0K Apr  5 13:51 logs
drwxr-xr-x. 2 root root 4.0K Apr  5 13:51 loot
drwxr-xr-x. 2 root root 4.0K Apr  5 13:51 modules
drwxr-xr-x. 2 root root 4.0K Apr  5 13:51 plugins

PierrickV on 5 Apr 2018

The .msf4 folder in your home directoy is owned by root. Execute a chown -R core:core and all will be working

FireFart on 5 Apr 2018

👍2

I'm not able to get it work on CoreOS :

core@my_vm01 ~/metasploit-framework $ sudo chown -R core:core ~/.msf4/
core@my_vm01 ~/metasploit-framework $ chmod 0664 /home/core/.msf4/logs/production.log
core@my_vm01 ~/metasploit-framework $ docker-compose run --rm --service-ports -e MSF_UID=$(id -u) -e MSF_GID=$(id -g) ms
Starting metasploitframework_db_1 ... done
Rails Error: Unable to access log file. Please ensure that /home/msf/.msf4/logs/production.log exists and is writable (ie, make it writable for user and group: chmod 0664 /home/msf/.msf4/logs/production.log). The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
Traceback (most recent call last):ork console...-
    12: from ./msfconsole:49:in `<main>'
    11: from /usr/src/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start'
    10: from /usr/src/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start'
     9: from /usr/src/metasploit-framework/lib/metasploit/framework/command/console.rb:62:in `driver'
     8: from /usr/src/metasploit-framework/lib/metasploit/framework/command/console.rb:62:in `new'
     7: from /usr/src/metasploit-framework/lib/msf/ui/console/driver.rb:74:in `initialize'
     6: from /usr/src/metasploit-framework/lib/msf/base/simple/framework.rb:73:in `create'
     5: from /usr/src/metasploit-framework/lib/msf/base/simple/framework.rb:111:in `simplify'
     4: from /usr/src/metasploit-framework/lib/msf/base/logging.rb:24:in `init'
     3: from /usr/src/metasploit-framework/lib/msf/base/logging.rb:24:in `new'
     2: from /usr/src/metasploit-framework/lib/rex/logging/sinks/flatfile.rb:21:in `initialize'
     1: from /usr/src/metasploit-framework/lib/rex/logging/sinks/flatfile.rb:21:in `new'
/usr/src/metasploit-framework/lib/rex/logging/sinks/flatfile.rb:21:in `initialize': Permission denied @ rb_sysopen - /home/msf/.msf4/logs/framework.log (Errno::EACCES)
core@my_vm01 ~/metasploit-framework $ ls -lah ~/
total 80K
drwxr-xr-x.  5 core core 4.0K Apr  5 12:12 .
drwxr-xr-x.  3 root root 4.0K Apr  3 05:47 ..
-rw-r--r--.  1 core core    0 Apr  5 10:05 .authorized_keys.d.lock
-rw-------.  1 core core 3.7K Apr  5 14:09 .bash_history
lrwxrwxrwx.  1 core core   33 Apr  3 05:47 .bash_logout -> ../../usr/share/skel/.bash_logout
lrwxrwxrwx.  1 core core   34 Apr  3 05:47 .bash_profile -> ../../usr/share/skel/.bash_profile
lrwxrwxrwx.  1 core core   28 Apr  3 05:47 .bashrc -> ../../usr/share/skel/.bashrc
drwxr-xr-x.  8 core core 4.0K Apr  5 13:51 .msf4
drwx------.  3 core core 4.0K Apr  5 10:05 .ssh
-rw-r--r--.  1 core core  180 Apr  5 10:06 .wget-hsts
-rw-r--r--.  1 core core  428 Apr  5 10:06 docker-compose.yml
drwxr-xr-x. 19 core core 4.0K Apr  5 15:55 metasploit-framework
core@my_vm01 ~/metasploit-framework $ ls -lah ~/.msf4/
total 64K
drwxr-xr-x. 8 core core 4.0K Apr  5 13:51 .
drwxr-xr-x. 5 core core 4.0K Apr  5 12:12 ..
drwxr-xr-x. 2 core core 4.0K Apr  5 13:51 local
drwxr-xr-x. 2 core core 4.0K Apr  5 13:51 logos
drwxr-xr-x. 3 core core 4.0K Apr  5 13:51 logs
drwxr-xr-x. 2 core core 4.0K Apr  5 13:51 loot
drwxr-xr-x. 2 core core 4.0K Apr  5 13:51 modules
drwxr-xr-x. 2 core core 4.0K Apr  5 13:51 plugins

But it works on Fedora :

[me@fedora metasploit-framework]$ sudo chown -R  me: /home/me/.msf4/
[me@fedora metasploit-framework]$ sudo docker-compose run --rm --service-ports -e MSF_UID=$(id -u) -e MSF_GID=$(id -g) ms
Starting metasploitframework_db_1 ... done
[-] ***rTing the Metasploit Framework console...|
[-] * WARNING: No database support: NilClass 
[-] ***

 _                                                    _
/ \    /\         __                         _   __  /_/ __
| |\  / | _____   \ \           ___   _____ | | /  \ _   \ \
| | \/| | | ___\ |- -|   /\    / __\ | -__/ | || | || | |- -|
|_|   | | | _|__  | |_  / -\ __\ \   | |    | | \__/| |  | |_
      |/  |____/  \___\/ /\ \\___/   \/     \__|    |_\  \___\


       =[ metasploit v5.0.0-dev                           ]
+ -- --=[ 1750 exploits - 1003 auxiliary - 304 post       ]
+ -- --=[ 536 payloads - 40 encoders - 10 nops            ]
+ -- --=[ ** This is Metasploit 5 development branch **   ]

[*] Processing docker/msfconsole.rc for ERB directives.
[*] resource (docker/msfconsole.rc)> Ruby Code (236 bytes)
LHOST => 172.24.0.3
[-] Unknown command: db_connect.
msf5 >

(I had to replace $HOME by /home/my_name/ otherwise the .msf4 is created in /root/ (This solution does not work for my CoreOS))
(Note : On Fedora I am not in the 'docker' group.)

I don't know if we can say that this issue is fixed

PierrickV on 5 Apr 2018

That's strange. Maybe the use of sudo mounts /root/ as $HOME? As the docker image is running as a non privileged user the UID needs to match. As a dirty workaround you can also pass the -u root flag to docker-compose so the container will run with root inside.
Are you using a standard coreos install so we can try to reproduce this?

FireFart on 5 Apr 2018

Yes, I followed this tutorial : https://coreos.com/os/docs/latest/booting-on-virtualbox.html

PierrickV on 7 Apr 2018

In my case the directory mentioned in the error ~/.msf4 had the root user as its owner

I solved the problem by changing the owner to my own user.

sudo chown -R $USER:$USER ~/.msf4/

OS
Ubuntu 20.04.1 LTS (Focal Fossa)

v3rlly on 26 Sep 2020

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.