dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2023-01-23T13:45:01Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1207Use safe replacement / check for abuse for tarfile.extractall()2023-01-23T13:45:01ZTimo Kochtimokoch@math.uio.noUse safe replacement / check for abuse for tarfile.extractall()See https://github.com/dumux/dumux/pull/1
This is a well-known Python `tarfile` vulnerability (got some media attention lately):
https://bugs.python.org/issue21109
we could use code from https://pypi.org/project/tarsafe/ (MIT license)
...See https://github.com/dumux/dumux/pull/1
This is a well-known Python `tarfile` vulnerability (got some media attention lately):
https://bugs.python.org/issue21109
we could use code from https://pypi.org/project/tarsafe/ (MIT license)
to fix this, I would prefer this over https://github.com/dumux/dumux/pull/1 which only checks for one vulnerability.
It's only a problem if someone manages to interfere with the tarballs that we obtain
from trusted sources via URLs. But would be good to add the safety checks from https://pypi.org/project/tarsafe/.
We use `extractall` in [installexternal.py](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/bin/installexternal.py#L202)Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/994dumux listens on TCP-Ports2021-08-20T19:41:18ZDavid Wernerdumux listens on TCP-PortsHaving opened TCP ports which are not needed is a security risk. A possible attack can be to inject buffers with arbitrary content. So this should not happen if not otherwise configured.
The ports are open on all IPv4-Adresses.
I see c...Having opened TCP ports which are not needed is a security risk. A possible attack can be to inject buffers with arbitrary content. So this should not happen if not otherwise configured.
The ports are open on all IPv4-Adresses.
I see currently two jobs on hal which have opened TCP Ports 1027 and 1028 for whatever reasons:
```
root@hal:/var/log# lsof -nP -iTCP -sTCP:LISTEN |grep 1027
test_pnm_ 608139 maziar 15u IPv4 2121895 0t0 TCP *:1027 (LISTEN)
root@hal:/var/log# lsof -nP -iTCP -sTCP:LISTEN |grep 1028
test_darc 771895 nepal 16u IPv4 2944280 0t0 TCP *:1028 (LISTEN)
```
Process of maziar looks in tool `pstree -u`
```
slurm_script(608134)───mpirun(608135)─┬─test_pnm_drop_s(608139)─┬─{test_pnm_drop_s}(608140)
│ └─{test_pnm_drop_s}(608141)
├─{mpirun}(608136)
├─{mpirun}(608137)
└─{mpirun}(608138)
```
And with `ps auxww | grep 608139`
```
maziar 608139 98.8 9.7 11601160 6429192 ? Rl Feb18 7995:05 ./test_pnm_drop_stokes_1p
```
Process of nepal looks like:
```
root@hal:/var/log# pstree -u nepal -p
slurm_script(771894)───test_darcy(771895)─┬─orted(771896)─┬─{orted}(771897)
│ ├─{orted}(771898)
│ └─{orted}(771899)
├─{test_darcy}(771900)
└─{test_darcy}(771901)
root@hal:/var/log# ps auxww |grep 771895
nepal 771895 99.9 0.0 238064 29196 ? Rl Feb22 2154:57 ./test_darcy test_darcy.input
```
It would be interesting to stop this and/or document at least its cause.
I have no idea of cause, it can be openmpi related but other things might be possible.