Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
> Please reconsider my suggestion made on 2022-01-14: Everybody wants to be a dev.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Mon, Jan 24, 2022 at 10:21:33AM +0100, Harald Dunkel wrote: > I highly appreciate the carefulness, but the error message doesn't > indicate a user "_pkgfetch", nor is it mentioned on pkg_add(1). > Please reconsider my suggestion made on 2022-01-14: > Note that smtpd(8) doesn't mention all the users and processes it used for privilege separation either. Those are implementation details and will work out-of-the-box unless you fiddle with parts you're not supposed to touch. and if you touch those parts... you're supposed to know where to look and how things work in the background.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
I highly appreciate the carefulness, but the error message doesn't indicate a user "_pkgfetch", nor is it mentioned on pkg_add(1). Please reconsider my suggestion made on 2022-01-14: > In general, if there is a permission problem due to file system > access bits, then it would be wise to include euid and egid in > the error message. Thank you very much Harri
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote: > On 2022-01-17 18:02:25, Marc Espie wrote: > > > > Lol. > > > > cert.pem only contains public certificates. Insisting on only root being > > able to read it means you are going to run code as root which doesn't > > require > > it. That seems way more unreasonable than your original assumption. > > > > I am not arguing about the access permissions (which I screwed > up), but I wonder why pkg_add run by root failed with EPERM? > Actually root was the only one *permitted* to access this file. > Thats not an error. Because we use this nifty technique called privilege separation to alleviate issues with bugs. Most specifically, pkg_add runs as root, which has wy too many rights, so it doesn't connect to the network directly, it starts ftp(1), which runs as _pkgfetch, which passes its result to signify which can check that the archive is properly signed before decompressing it with the zlib and finally putting the result on your disk. It's not rocket science, privilege separation has been around for over 20 years at this point ;)
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote: > On 2022-01-17 18:02:25, Marc Espie wrote: > > > > Lol. > > > > cert.pem only contains public certificates. Insisting on only root being > > able to read it means you are going to run code as root which doesn't > > require > > it. That seems way more unreasonable than your original assumption. > > > > I am not arguing about the access permissions (which I screwed > up), but I wonder why pkg_add run by root failed with EPERM? > Actually root was the only one *permitted* to access this file. > Thats not an error. > > If there was another user account involved, then show me. The user is called _pkgfetch -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-17 18:02:25, Marc Espie wrote: Lol. cert.pem only contains public certificates. Insisting on only root being able to read it means you are going to run code as root which doesn't require it. That seems way more unreasonable than your original assumption. I am not arguing about the access permissions (which I screwed up), but I wonder why pkg_add run by root failed with EPERM? Actually root was the only one *permitted* to access this file. Thats not an error. If there was another user account involved, then show me.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14, Harald Dunkel wrote: > On 2022-01-14 10:42:56, Harald Dunkel wrote: >> >> Hi folks, >> >> trying to upgrade the installed packages I get >> >> # pkg_add -u >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > chmod a+rx /etc/ssl > > did the trick, but this doesn't look reasonable. Lol. cert.pem only contains public certificates. Insisting on only root being able to read it means you are going to run code as root which doesn't require it. That seems way more unreasonable than your original assumption.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
OpenBSD default is for /etc/ssl/ to be root:wheel u+w,a+rx Harold, you broke your own machine. Stuart Henderson wrote: > On 2022-01-14, Harald Dunkel wrote: > > On 2022-01-14 10:42:56, Harald Dunkel wrote: > >> > >> Hi folks, > >> > >> trying to upgrade the installed packages I get > >> > >> # pkg_add -u > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS > >> connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission > >> denied > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect > >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty > >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > > > chmod a+rx /etc/ssl > > > > did the trick, but this doesn't look reasonable. > > Why would that not be reasonable? It's setting it back to the default > permissions after whatever change you've made to it. > > There are various system daemons and utilities (including sysupgrade, > syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will > want to make TLS connections as a non-root user, at least in some > configurations. Some of these may open cert.pem while they still have > privileges but not always. > > > In general, if there is a permission problem due to file system > > access bits, then it would be wise to include euid and egid in > > the error message. > > Not sure if that helps really. If you'd seen that, maybe you would have > fixed it for _pkgfetch and not noticed some other software that would > like to use it.. > >
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14, Harald Dunkel wrote: > On 2022-01-14 10:42:56, Harald Dunkel wrote: >> >> Hi folks, >> >> trying to upgrade the installed packages I get >> >> # pkg_add -u >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > chmod a+rx /etc/ssl > > did the trick, but this doesn't look reasonable. Why would that not be reasonable? It's setting it back to the default permissions after whatever change you've made to it. There are various system daemons and utilities (including sysupgrade, syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will want to make TLS connections as a non-root user, at least in some configurations. Some of these may open cert.pem while they still have privileges but not always. > In general, if there is a permission problem due to file system > access bits, then it would be wise to include euid and egid in > the error message. Not sure if that helps really. If you'd seen that, maybe you would have fixed it for _pkgfetch and not noticed some other software that would like to use it..
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
| This happens on 2 OpenBSD hosts. On 5 others there is no such problem. Do you have an explanation why the 2 host out of 7 are behaving different? I don't find it "reasonable" that 2 host out of 7 manifest some different behavior on their own.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14 10:42:56, Harald Dunkel wrote: Hi folks, trying to upgrade the installed packages I get # pkg_add -u https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... chmod a+rx /etc/ssl did the trick, but this doesn't look reasonable. In general, if there is a permission problem due to file system access bits, then it would be wise to include euid and egid in the error message. Harri
