On Tue, 22 May 2018 06:04:57 +0300 IL Ka <kazakevichi...@gmail.com> wrote: > I am definitely not an expert in this field, but here are some > thoughts: Exactly. There is always more than one way to skin a cat. I'm not looking for a perfectly spelled out "solution" I must follow to the letter.
> So, you can create "_fastcgi" group, add www to this group, and > configure php-fpm > to create socket with this group (it must be main group of user used > by php-fpm). I was thinking more the other way around: creating a "_fastcgi" *user* and inviting that user into the "www" group. > See listen.group and listen.mode options. These are a little odd because OpenBSD's httpd apparently refuses to connect to the php fastcgi socket unless these are both set to "www" in /etc/php-fpm.conf > In PHP world maybe, but for Python/Django Postgres is default > database. Sure. There are plenty of good reasons to consider languages other than PHP for the web. > Again, you can add _postgres to some group, and give it permissions to > create socket in this folder. Very good observation. > > although the chrooted user must specify the username together with a > > dummy password (which is not used) to connect to the socket inside > > the chroot, apparently because there is no access to /etc/passwd > > or /etc/group inside the chroot. > > > /etc/passwd must be accessed by postgres (which is not chrooted, > right?) but not by client. > Client (php) just opens socket file, and postgres uses openbsd API to > get its user id. The client (inside the chroot) has its numeric userid, but cannot even look up its own username (in /etc/passwd) from inside the chroot to supply to PostgreSQL for the connection. That's why it must be specified manually from within the chroot.
