Hi,
I'm working on a registry for +31 ENUM, using Knot DNS 2.6.8. The
intention is to trigger the Python API from PostgreSQL database views.
The postgres user, though added to the knot group and granted rw- on all
of /var/db/knot/* and the knotd socket, cannot do thinkgs like conf-read
through the Python API or knotc.
This is where root and the postgres user diverge:
84630 knotc CALL
open(0x7fffffffe100,0x100022<O_RDWR|O_EXLOCK|O_CLOEXEC>)
84630 knotc NAMI "/tmp/SEMDMDBrXFzK!_#un)"
84630 knotc RET open 6
84630 knotc CALL fstat(0x6,0x7fffffffe068)
84630 knotc STRU struct stat {dev=4261341516, ino=125942,
mode=0100660, nlink=1, uid=0, gid=0, rdev=4294967295,
atime=1545172776.416579000, mtime=1545182138.348328000,
ctime=1545182138.348328000, birthtime=1545172776.416478000, size=16,
blksize=4096, blocks=2, flags=0x800 }
That's root. uid=0 and gid=0 for the /tmp/SENDMDB... file. But now:
84649 knotc CALL
open(0x7fffffffe0f0,0x100022<O_RDWR|O_EXLOCK|O_CLOEXEC>)
84649 knotc NAMI "/tmp/SEMDMDBrXFzK!_#un)"
84649 knotc RET open -1 errno 13 Permission denied
That's user postgres, even though it is in the knot group. It seems to
see the file but have no access, probably due to uid=0, gid=0.
Note that matching name.
--> What is this file it is trying to open, and is it always mapped to
uid=0,gid=0, even if the user running "knotc conf-read" is not root?
Could this be a FreeBSD things, or a jail thing?
Any advise is welcome!
Thanks!
-Rick