etingof / snmpsim

SNMP Simulator
http://snmplabs.com/snmpsim/
BSD 2-Clause "Simplified" License
383 stars 120 forks source link

Option to disable uid=0 check #156

Closed silverwind closed 4 months ago

silverwind commented 3 years ago

Inside Docker containers it's often unavoidable/necessary to run processes as uid 0 but this module stubbornly refuses to run as uid 0.

I've monkey-patched the module to remove that check and everything seems to work fine so far so I'd suggest having an option like --allow-root or better yet, remove this opinionated check.

gainskills commented 3 years ago

do you meet any issue when running snmpsim in docker?

silverwind commented 3 years ago

It will refuse to run inside Docker as root at all with the Must drop privileges error. After I patched out that check, it runs just fine.

I run snmpsim inside a CI environment which always runs its jobs as uid=0 and I tried the --process-user=nobody and --process-group=nogroup arguments but then I ran into tempfiles permission errors (presumably fixed by https://github.com/etingof/snmpsim/commit/e9e1d5b8103cbe93f474de6e4a952dac7d06f41d but not released), so I gave up and patched out that check.

gainskills commented 3 years ago

It will refuse to run inside Docker as root at all with the Must drop privileges error. After I patched out that check, it runs just fine.

I run snmpsim inside a CI environment which always runs its jobs as uid=0 and I tried the --process-user=nobody and --process-group=nogroup arguments but then I ran into tempfiles permission errors (presumably fixed by e9e1d5b but not released), so I gave up and patched out that check.

can you try with the master edition?

silverwind commented 3 years ago

Regardless whether master works or not, I think the uid check needs to go or be disableable.

gainskills commented 3 years ago

I totally understand what you concern about, but, not fix the issue by talking, I would say each layer has different specs to consider. Make a note about the steps what I did for a workaround:

snmpsim @ https://github.com/etingof/snmpsim/zipball/master
# Pull base image
FROM python:3.9.0-alpine3.12
MAINTAINER authoer@gmail.com

# Set environment variables
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

# Update
RUN apk update && apk upgrade
RUN apk add build-base gcc

# set work directory
RUN mkdir /usr/test
# copy project
COPY ./requirements.txt /usr/test/requirements.txt

WORKDIR /usr/test

# install dependencies
RUN pip install --no-cache-dir --upgrade pip
# RUN pip install --no-cache-dir -U -r requirements-git.txt
RUN pip install --no-cache-dir -U -r requirements.txt

# Cleanup
Run rm -rf /var/cache/apk/* /root/.node-gyp /usr/share/man /tmp/*
docker run snmpsim /bin/sh -c "snmpsim-command-responder --process-user=nobody --process-group=nogroup --agent-udpv4-endpoint=127.0.0.1:1024"

and

docker run snmpsim /bin/sh -c "snmpsim-command-responder --process-user=root --process-group=root --agent-udpv4-endpoint=127.0.0.1:1024"

SNMPSim can be started image

silverwind commented 3 years ago

I use poetry and have snmpsim as a devDependency like

[tool.poetry.dev-dependencies]
snmpsim = "^0.4.7" 

I guess I can try changing that to point to github master and try the uid/gid workaround, but it's just that, a workaround. I'm of the strong opinion that such uid checks have no place in a module like this.

I'm aware that it's dangerous to run stuff as root, but I accept that risk because my CI environment does not offer any other option and it's not inherently unsafe because it runs in a isolated container.

frogmaster commented 3 years ago

I agree with silverwind, the workaround is completely non-obvious, who would have thought you can provide root to process-user. I've spent a day messing with the permissions until i stumbled upon this issue.

silverwind commented 4 months ago

https://github.com/lextudio/snmpsim has removed this uid check, so I'll be using that.

silverwind commented 4 months ago

Seems I mislooked and snmpsim-lextudio still features this stupd uid check, so I'm back to monkey-patching.

Reason I have to do it is I'm running inside a specific CI environment where it's not easy to drop privileges like it would in plain docker. https://github.com/moby/moby/issues/2259 is also a dependency.