Pledge problems on OpenBSD 6.0?
hrkfdn opened this issue · comments
Hey,
I know this setup is probably unsupported, but I'm wondering whether I found a bug:
Just built acme-client from CVS HEAD on OpenBSD 6.0. Whenever I try to request a certificate, the process gets terminated (due to missing pledge priviledges?):
ira ~ # acme-client -vvvAD domain.org
acme-client: /etc/ssl/acme/private/privkey.pem: domain key exists (not creating)
acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not creating)
acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
acme-client: /etc/ssl/acme/private/privkey.pem: loaded RSA domain key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 23.62.131.169
acme-client: signal: netproc(9472): Abort trap
dmesg lists the following:
acme-client(9472): syscall 5 "rpath"
and a backtrace:
ira ~ # gdb /usr/sbin/acme-client acme-client.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.0"...
Core was generated by `acme-client'.
Program terminated with signal 6, Aborted.
Loaded symbols for /usr/sbin/acme-client
Reading symbols from /usr/lib/libtls.so.11.0...done.
Loaded symbols for /usr/lib/libtls.so.11.0
Reading symbols from /usr/lib/libssl.so.39.0...done.
Loaded symbols for /usr/lib/libssl.so.39.0
Reading symbols from /usr/lib/libcrypto.so.38.0...done.
Loaded symbols for /usr/lib/libcrypto.so.38.0
Reading symbols from /usr/lib/libc.so.88.0...done.
Loaded symbols for /usr/lib/libc.so.88.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0 0x00000b4d84c878ba in _thread_sys_open () at <stdin>:2
2 <stdin>: No such file or directory.
in <stdin>
(gdb) bt
#0 0x00000b4d84c878ba in _thread_sys_open () at <stdin>:2
#1 0x00000b4d84cf3ec9 in *_libc_open_cancel (path=Variable "path" is not available.
) at /usr/src/lib/libc/sys/w_open.c:36
#2 0x00000b4d84c85dc2 in *_libc_fopen (file=0xb4cf0d08fc0 "/etc/ssl/cert.pem", mode=Variable "mode" is not available.
) at /usr/src/lib/libc/stdio/fopen.c:54
#3 0x00000b4d14df6a8e in BIO_new_file (filename=0xb4cf0d08fc0 "/etc/ssl/cert.pem", mode=0xb4d14f9fc63 "r")
at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:119
#4 0x00000b4d14e6914f in X509_load_cert_crl_file (ctx=0xb4cd4a84b00, file=Variable "file" is not available.
)
at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/x509/by_file.c:249
#5 0x00000b4d14e692af in by_file_ctrl (ctx=0xb4cd4a84b00, cmd=Variable "cmd" is not available.
)
at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/x509/by_file.c:110
#6 0x00000b4d14e094ee in X509_STORE_load_locations (ctx=0xb4d63666e00, file=0xb4cf0d08fc0 "/etc/ssl/cert.pem", path=0x0)
at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/x509/x509_d2.c:96
#7 0x00000b4d96636739 in tls_configure_ssl_verify (ctx=0xb4da9333680, verify=Variable "verify" is not available.
) at tls.c:348
#8 0x00000b4d96638ac0 in tls_connect_fds (ctx=0xb4da9333680, fd_read=3, fd_write=3,
servername=0xb4d3d733960 "acme-v01.api.letsencrypt.org") at tls_client.c:208
#9 0x00000b4ac6e06e1a in http_alloc (addrs=0x7f7ffffed630, addrsz=1, host=0xb4d3ce49f40 "acme-v01.api.letsencrypt.org", port=443,
path=0xb4d7e135e10 "/directory") at http.c:325
#10 0x00000b4ac6e07a8e in http_get (addrs=0x7f7ffffed630, addrsz=1, domain=0xb4d3ce49f40 "acme-v01.api.letsencrypt.org", port=443,
path=0xb4d7e135e10 "/directory", post=0x0, postsz=0) at http.c:690
#11 0x00000b4ac6e0b6f1 in nreq (c=0x7f7ffffed7a0, addr=0xb4d9b211880 "https://acme-v01.api.letsencrypt.org/directory")
at netproc.c:199
#12 0x00000b4ac6e0c413 in dodirs (c=0x7f7ffffed7a0, addr=0xb4d9b211880 "https://acme-v01.api.letsencrypt.org/directory",
paths=0x7f7ffffed780) at netproc.c:522
#13 0x00000b4ac6e0c81a in netproc (kfd=4, afd=6, Cfd=8, cfd=10, dfd=14, rfd=16, newacct=0, revocate=0, authority=0xb4d8535ba00,
alts=0xb4d98e33a40, altsz=8, agreement=0xb4da9333580 "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf")
at netproc.c:654
#14 0x00000b4ac6e0aadf in main (argc=0, argv=0x7f7ffffeda00) at main.c:262
Current language: auto; currently asm
(gdb)
Okay, it seems that rpath priviledges are required to open up TLS connections in netproc on OpenBSD 6.0, as /etc/ssl/cert.pem needs to be loaded. Not dropping rpath in netproc in the second pledge call "fixes" it, but obviously works around the design.
I'm assuming this is different on -CURRENT and thus part of my setup. I'll close this report.