Permission Error of Tun devices
I’m running several applications use tun devices as a non-root user. My hostname.tunX file is like: # /etc/hostname.tun0 inet 192.168.37.4 255.255.255.254 NONE dest 192.168.37.3 mtu 1436 !/sbin/chown tunuser:tunuser /dev/\$if They worked great until recently. I noticed causal permission error (error number 13) leading to the applications crashed. It occurs like once per 2 ~ 3 days after I upgraded the system to 6.8. Does anyone have clues about the reason of permission denials? Siegfried siegfried.le...@gmail.com
EACCES of UDP packet
Hi, I have a application run by a normal user communicating with the server with UDP. It crashes very occasionally, like once per week, due to EACCES when sending a UDP packet. According to the manpage (https://man.openbsd.org/OpenBSD-6.9/sendmsg.2#EACCES), the reason might be either being blocked by PF or sending to a broadcast address. I can confirm the packet was not sent to a broadcast address. However, I cannot figure out what rule could block the connection occasionally either. The application can be brought back online without changing any configuration. Does anyone know what might fix this? I can also rewrite the code to make it ignore the error and keep trying but that might not be a proper solution. Running it as root might not be a good idea, too. It happens since OpenBSD 6.8. Now I’m running it on 6.9. The application is written in Rust. Siegfried siegfried.le...@gmail.com
Re: EACCES of UDP packet
Thanks a lot for the hint. Unfortunately I’m still not able to see why sendto
failed with 13 Permission denied. The AF_INET address masked is the correct one
of my server, not a broadcast address. A sendto before this one to the same
address just worked.
3058 myapp CALL
sendto(5,0x1689f5f6500,0x5d,0x400,0x7f7f1144,0x10)
3058 myapp STRU struct sockaddr { AF_INET, xxx.xxx.xxx.xxx: }
3058 myapp RET sendto -1 errno 13 Permission denied
3058 myapp CALL close(5)
3058 myapp RET close 0
The dump file is like 600MB. I can provide more trace log if it is necessary
for locating the root cause.
Siegfried
siegfried.le...@gmail.com
> On Jun 15, 2021, at 8:50 PM, Theo de Raadt wrote:
>
> use ktrace
>
> Siegfried Levin wrote:
>
>> Hi,
>>
>> I have a application run by a normal user communicating with the server with
>> UDP. It crashes very occasionally, like once per week, due to EACCES when
>> sending a UDP packet. According to the manpage
>> (https://man.openbsd.org/OpenBSD-6.9/sendmsg.2#EACCES), the reason might be
>> either being blocked by PF or sending to a broadcast address. I can confirm
>> the packet was not sent to a broadcast address. However, I cannot figure out
>> what rule could block the connection occasionally either. The application
>> can be brought back online without changing any configuration. Does anyone
>> know what might fix this? I can also rewrite the code to make it ignore the
>> error and keep trying but that might not be a proper solution. Running it as
>> root might not be a good idea, too.
>>
>> It happens since OpenBSD 6.8. Now I’m running it on 6.9. The application is
>> written in Rust.
>>
>> Siegfried
>> siegfried.le...@gmail.com
>>
>>
>>
>>
Re: EACCES of UDP packet
y unavailable
3058 myapp CALL read(7,0x7f7f07e0,0xc)
3058 myapp GIO fd 7 read 12 bytes
"\M^T\M-|\M-e\M-Fk-\M^P\M-u}\M-j\M^U="
3058 myapp RET read 12/0xc
3058 myapp CALL
sendto(5,0x1690776a500,0x63,0x400,0x7f7f1144,0x10)
3058 myapp STRU struct sockaddr { AF_INET, xxx.xx.xxx.xx:y }
3058 myapp GIO fd 5 wrote 99 bytes
"\M-3\M-l7X{PM[\M^[\M^S\M-Rv:\M^C2\^_=-?\M^[\M-p\M-Kq;/0\M^_\M-`\M-Yx\M-B_\^CyX\M-B\M^?\M^N\M^H\M-[ykO\M-d\M-qg\M-]\M^L\M-BulvAF\M-"\M-d%)\M-Y\M-mK*`\M^L\M^B\M-I\
\M-5\^B\M-/<\M-?\0005\^Y3\M^?q\M-n\M^Ui\M-^\M^?\M^X!\M-w\^RA\M^T\M-|\M-e\M-Fk-\M^P\M-u}\M-j\M^U="
3058 myapp RET sendto 99/0x63
3058 myapp CALL kevent(3,0,0,0x168a7f0c000,128,0)
3058 myapp STRU struct kevent { ident=4, filter=EVFILT_READ,
flags=0x61, fflags=0<>, data=69, udata=0x2 }
3058 myapp RET kevent 1
3058 myapp CALL read(4,0x7f7f0af0,0x7d0)
3058 myapp GIO fd 4 read 69 bytes
"\0\0\0\^BE\0\0AHN\0\0@\^Q\^Q\M-1\M-@\M-(_\^D\^A\0\0\^A\M-u\M-D\0005\0-\M-w\r{\M-{\^A\0\0\^A\0\0\0\0\0\^A\^Dpow7\^Ccom\0\0\^A\0\^A\0\0)\^D\M-P\0\0\M^@\0\0\0"
3058 myapp RET read 69/0x45
3058 myapp CALL read(4,0x7f7f0af0,0x7d0)
3058 myapp GIO fd 4 read 79 bytes
"\0\0\0\^BE\0\0K\M-{\M-3\0\0@\^Q^A\M-@\M-(_\^D\^A\0\0\^A\M-U\M^F\0005\0007\^V\M-J\M^C\M^L\^A\0\0\^A\0\0\0\0\0\^A\atracker\^Fcity9x\^Ccom\0\0\^A\0\^A\0\0)\^D\M-P\0\0\
\M^@\0\0\0"
3058 myapp RET read 79/0x4f
3058 myapp CALL read(4,0x7f7f0af0,0x7d0)
3058 myapp RET read -1 errno 35 Resource temporarily unavailable
3058 myapp CALL read(7,0x7f7f07e0,0xc)
3058 myapp GIO fd 7 read 12 bytes
"\M^Xr\M-r\M-[%\M-n\\\M^L\M-e&\M^_\M-i"
3058 myapp RET read 12/0xc
3058 myapp CALL
sendto(5,0x1689f5f6500,0x5d,0x400,0x7f7f1144,0x10)
3058 myapp STRU struct sockaddr { AF_INET, xxx.xx.xxx.xx:y }
3058 myapp RET sendto -1 errno 13 Permission denied
3058 myapp CALL close(5)
3058 myapp RET close 0
3058 myapp CALL munmap(0x1688d3c8000,0x1a1000)
3058 myapp RET munmap 0
3058 myapp CALL munmap(0x169192ad000,0x1a1000)
3058 myapp RET munmap 0
3058 myapp CALL munmap(0x1691cb22000,0x1a1000)
3058 myapp RET munmap 0
3058 myapp CALL munmap(0x168220f8000,0x1a1000)
3058 myapp RET munmap 0
3058 myapp CALL close(4)
3058 myapp RET close 0
3058 myapp CALL close(3)
3058 myapp RET close 0
Siegfried
siegfried.le...@gmail.com
> On Jun 22, 2021, at 3:20 PM, Philip Guenther wrote:
>
> On Mon, Jun 21, 2021 at 9:07 PM Siegfried Levin <mailto:siegfried.le...@gmail.com>> wrote:
> Thanks a lot for the hint. Unfortunately I’m still not able to see why sendto
> failed with 13 Permission denied. The AF_INET address masked is the correct
> one of my server, not a broadcast address. A sendto before this one to the
> same address just worked.
>
> 3058 myapp CALL
> sendto(5,0x1689f5f6500,0x5d,0x400,0x7f7f1144,0x10)
> 3058 myapp STRU struct sockaddr { AF_INET, xxx.xxx.xxx.xxx: }
>
> Why have you chosen to hide information that may be useful in debugging your
> problem?
>
> "Hi, I'm asking for help but I have to hide addresses because...this
> application is insecure if anyone else has its IP+port? Because I've never
> heard of shodan and don't believe that people are constantly scanning the
> Internet? And while I don't know why it's failing I'm 1000% sure that
> there's no information to be gained from seeing the IP, so if it later turns
> out my understanding of 'broadcast address' is incorrect, the time I've
> wasted for myself and others will be...a total loss?"
>
>
> 3058 myapp RET sendto -1 errno 13 Permission denied
> 3058 myapp CALL close(5)
> 3058 myapp RET close 0
> The dump file is like 600MB. I can provide more trace log if it is necessary
> for locating the root cause.
>
> Use the scientific method:
> * make a testable hypothesis
> * devise a test for that
> * perform the test
> * determine whether the hypothesis has been ruled out or confirmed
>
> So, since the manpage mentions blocking pf, I suggest the hypothesis "it
> returns EACCES because pf is blocking your packets". I can think of several
> ways to test that; what testing have you performed to confirm or rule out
> that possibility? "doas pfctl -d; run test; doas pfctl -e"?
>
>
> Alternatively: what's different about *that* call? Does every sento() call
> on that socket fail? What is special about that socket? If other sendto()
> calls succeed, what is different about that call? Earlier setsockopt() calls?
>
>
> You say "I can confirm the packet was no
All my Rust programs stop working on OpenBSD 7.3
After I upgraded my OS from 7.2 to 7.3 with sysupgrade like 8 hours ago, all my programs written in Rust broke, including cargo installed with pkg_add on 7.2. I fixed Cargo by “pkg_add -u rust” and then recompiled some of my projects. Now they are having segment faults. Does anyone having the same error? PS: just realized I upgraded to 7.3 before it was officially announced 3 hours ago. Could that cause any issues?
Re: All my Rust programs stop working on OpenBSD 7.3
Thanks. Actually that’s what I did. Rust package was updated by “pkg_add -u rust” and then “cargo build —release” rebuilds the projects. However, when I ran it, it crashed because of segment fault. It no longer passes the tests as well, “invalid memory reference” was returned. > On Apr 11, 2023, at 00:09, Sebastien Marie wrote: > > On Mon, Apr 10, 2023 at 11:49:50PM +0800, Siegfried Levin wrote: >> After I upgraded my OS from 7.2 to 7.3 with sysupgrade like 8 hours ago, all >> my programs written in Rust broke, including cargo installed with pkg_add on >> 7.2. I fixed Cargo by “pkg_add -u rust” and then recompiled some of my >> projects. Now they are having segment faults. Does anyone having the same >> error? > > you need to rebuild your locally built programs with rustc from 7.3. > > first, upgrade rustc/cargo with pkg_add -u, and next rebuild your programs as > usually, that's all. > > for the long story: 7.3 comes with immutable stack, but old rust programs are > modifying it (so the kernel kills your programs). > > the updated package has the required changes in rust std library. but you > will > need to rebuild your programs to make them to use the updated code (the > faulty > code is in rust std which is statically linked in all programs). > > Thanks. > -- > Sebastien Marie
Re: All my Rust programs stop working on OpenBSD 7.3
Thanks. I believe that is the reason. > On Apr 11, 2023, at 02:54, Theo Buehler wrote: > > >> >> Thanks. Actually that’s what I did. Rust package was updated by >> “pkg_add -u rust” and then “cargo build —release” rebuilds the >> projects. However, when I ran it, it crashed because of segment fault. >> It no longer passes the tests as well, “invalid memory reference” was >> returned. > > Without seeing a backtrace it is difficult to tell. > > Another issue could be that you use things depending on the ring crate > whose assembly isn't compatible with the new x-only protection on modern > amd64 machines. > > If so, you will need to > > # pkg_add rust-ring > > and replace lines like this > > ring = "^0.16" > > with something like this in Cargo.toml: > > [dependencies.ring] > version = "^0.16" > path = "/usr/local/share/ring-0.16.20"
Re: All my Rust programs stop working on OpenBSD 7.3
I checked the core dump again. There is still an error on Ring 0.16.20. Where can I know more about the protection introduced in 7.3 in case that I need to report this on GitHub? Thanks. Reading symbols from /usr/libexec/ld.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] #0 GFp_sha512_block_data_order_avx () at /mnt/warehouse/home/git/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/sha512-x86_64-elf.S:1881 1881vpaddq -128(%rbp),%xmm0,%xmm8 > On Apr 11, 2023, at 02:54, Theo Buehler wrote: > > >> >> Thanks. Actually that’s what I did. Rust package was updated by >> “pkg_add -u rust” and then “cargo build —release” rebuilds the >> projects. However, when I ran it, it crashed because of segment fault. >> It no longer passes the tests as well, “invalid memory reference” was >> returned. > > Without seeing a backtrace it is difficult to tell. > > Another issue could be that you use things depending on the ring crate > whose assembly isn't compatible with the new x-only protection on modern > amd64 machines. > > If so, you will need to > > # pkg_add rust-ring > > and replace lines like this > > ring = "^0.16" > > with something like this in Cargo.toml: > > [dependencies.ring] > version = "^0.16" > path = "/usr/local/share/ring-0.16.20"
Re: All my Rust programs stop working on OpenBSD 7.3
Oh shoot! Sorry I misunderstood the solution. I got rust-ring package installed and tried Laurie’s recipe. Now all errors are gone. Thanks a lot! > On Apr 11, 2023, at 17:06, Theo Buehler wrote: > > On Tue, Apr 11, 2023 at 04:43:04PM +0800, Siegfried Levin wrote: >> I checked the core dump again. There is still an error on Ring 0.16.20. > > Yes, that's expected. If you read my mail again, I told you to use the > patched source in /usr/local/share/ring-0.16.20 from the rust-ring > package, not simply ring 0.16.20. Once again: if Cargo.toml contains > > [dependencies] > ... > ring = "^0.16" > ... > > or similar, remove the ring line from [dependencies] and add a new section > > [dependencies.ring] > version = "^0.16" > path = "/usr/local/share/ring-0.16.20" > > Or you can follow Laurie Tratt's recpie. > >> Where can I know more about the protection introduced in 7.3 in case that I >> need to report this on GitHub? Thanks. > > I don't think it's going to be useful to report this on github. I will > try to upstream the patches when I will find time to do so. It's a bit > of a tricky patchset since ring uses assembly from BoringSSL and targets > various platforms I don't have easy access to, so I can't upstream the > patches as they currently are in the port. > >> Reading symbols from /usr/libexec/ld.so...Error while reading shared library >> symbols: >> Dwarf Error: wrong version in compilation unit header (is 4, should be 2) >> [in module /usr/libexec/ld.so] >> #0 GFp_sha512_block_data_order_avx () at >> /mnt/warehouse/home/git/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/sha512-x86_64-elf.S:1881 >> 1881 vpaddq -128(%rbp),%xmm0,%xmm8 > > Yes, as expected. > >> >>> On Apr 11, 2023, at 02:54, Theo Buehler wrote: >>> >>> >>>> >>>> Thanks. Actually that’s what I did. Rust package was updated by >>>> “pkg_add -u rust” and then “cargo build —release” rebuilds the >>>> projects. However, when I ran it, it crashed because of segment fault. >>>> It no longer passes the tests as well, “invalid memory reference” was >>>> returned. >>> >>> Without seeing a backtrace it is difficult to tell. >>> >>> Another issue could be that you use things depending on the ring crate >>> whose assembly isn't compatible with the new x-only protection on modern >>> amd64 machines. >>> >>> If so, you will need to >>> >>> # pkg_add rust-ring >>> >>> and replace lines like this >>> >>> ring = "^0.16" >>> >>> with something like this in Cargo.toml: >>> >>> [dependencies.ring] >>> version = "^0.16" >>> path = "/usr/local/share/ring-0.16.20"
Alpine Linux guest running slow after upgraded to OpenBSD 7.0
An Alpine Linux 3.10 guest VM is running quite slow after I upgraded the host to 7.0. It takes quite long to get a response. Other OpenBSD guests seems ok. Is anyone having the same issue? Thanks. Siegfried siegfried.le...@gmail.com
doas hang suddenly
My server has been running for weeks without an issue. It is running OpenBSD 7.1. However, today I suddenly cannot use doas anymore. It always hang. Has anyone met this issue before? Siegfried siegfried.le...@gmail.com
Re: doas hang suddenly
Weird. I did nothing but it recovered. I’ll check it again when it’s hanging. Thanks for you help. Siegfried siegfried.le...@gmail.com > On Jun 22, 2022, at 15:27, Stuart Henderson wrote: > > On 2022-06-22, Siegfried Levin wrote: >> My server has been running for weeks without an issue. It is running OpenBSD >> 7.1. However, today I suddenly cannot use doas anymore. It always hang. Has >> anyone met this issue before? > > How does the doas process look in top(1) when it's hanging? > > -- > Please keep replies on the mailing list. >
