Aug 15 2021
Linking for convenience, a cgit range that inclues the four commits: https://cgit.freebsd.org/src/log/?qt=range&q=7f4e724829e556fc646056669c2af3551b7e8724...67af9aba6b144789734289443a5f90a3ca716dbe
Jul 20 2021
Jun 25 2021
Jun 14 2021
Jun 13 2021
Im don't understand what do you mean, I mean that musl it's a separate brand, see Elf_Brandinfo and linux_sysvec.c,
and only for musl brand we should change cmp_requeue, for glibc brand cmp_requeue should return EINVAL
Jun 11 2021
Jun 6 2021
Jun 5 2021
Jun 1 2021
FWIW, splice: https://reviews.freebsd.org/D30597
May 25 2021
we have so many such unfinished things
Why do we need it? All the BSD's seem to exist without splice() just fine?
The most pressing issue is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.
https://wiki.freebsd.org/Linuxulator#Roadmap, pi is not the key, we have so many important holes
It's literally the second item on that list, for example pulseaudio hard crashes because it's not there. I have started but it's pretty hard, I wonder if anyone can help?
FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono.
I don't think they are even usable, since the core file is in FreeBSD format that linux gdb can't parse, and confuse the freebsd gdb because it's a linux process/elf.
we have so many such unfinished things, like arm linuxulator, splice sys call....
Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.
Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.
Is there a way to config git to do that by default? It's annoying to do every time.
May 24 2021
hi, what is the purpose for this? it will be used read only. so what is the program depend on it?
For future uploads please include full context by using e.g. git show -U99999 <hash> - see https://wiki.freebsd.org/Phabricator for details
May 21 2021
May 18 2021
May 15 2021
Do we have an agreement there?
May 13 2021
All kinds of cases, tbh - from sudo apt update, to Chromium, which (for some reason) depends on a setuid helper.
May 12 2021
May 9 2021
Switch to allow by default
I've tested this patch for both 64, and 32-bit Linux binaries, for both suid and sgid bit, and it works just fine.
Sure, I'll test it.
May 6 2021
Add some explanation to man page.
May 5 2021
Note that I'm not in any way opposed to this change.
Mar 24 2021
Fully support this change and motivation, propose to add a short description to the linux(4) manual about sysctl
Mar 23 2021
Mar 7 2021
Also: I wonder if we could start allowing chroot(2) for non-root users, as long as the calling process has the NO_NEW_PRIVS flag set.
Mar 6 2021
I'm not convinced about the environment, tbh. Can you give some specific example of what we don't provide, that could affect security of suid binaries?
Feb 3 2021
Feb 2 2021
Feb 1 2021
Motivation is provided by the notes in the referenced PR. Briefly, convincing argument for me was that we do not provide environment that would be expected by the linux setuid binaries, so assumptions made during coding of them could be broken by us unknowingly. More, I should add that it is possible that user break them due to our /compat/linux+normal freebsd fs fallback setup.
I'm not sure this is all that useful, to be honest. What's the usage scenario? Why would one globally disable suid for Linux binaries?
Jan 19 2021
Make changes on source file instead of file in destination location (/etc/rc.d/linux). Use sysctl-variable for all occurences of hardcoded path of /compat/linux.