I didn't realize you were using coloured cursors.
You make me sad. You don't know what the bug is. You don't know how to
reproduce it. You don't have a plausible call path. You grep, and yet
don't dig deeper to see if that code you find is initialization phase or
activated later during runtime after the pledge call.
Essentially, you don't attempt any of the processes we call
"development", but hey, here's a diff...
Your answer when encountering pledge adversity, to add all the required
pledges, and not look deeper.
As I say, it makes me sad.
This should be looked into deeper, and we may decide that whatever thing
xterm is doing here should be disabled.
Leonid Bobrov <mazoc...@disroot.org> wrote:
> Like I said yesterday, I don't know how to reproduce this bug, it just
> happened to me and I got this dmesg(1):
> xterm[90461]: pledge "cpath", syscall 5
>
> Right now I quickly grep(1)'ed xterm(1)'s source code:
> mazocomp$ egrep "mkdir\(|unlink\(|rmdir\(" -R . -n
> ./misc.c:760: && mkdir(filename, 0700) == 0) {
> ./misc.c:804: unlink(xterm_cursor_theme);
> ./misc.c:805: rmdir(my_path);
>
> The diff below should fix it:
>
> Index: main.c
> ===================================================================
> RCS file: /cvs/xenocara/app/xterm/main.c,v
> retrieving revision 1.43
> diff -u -p -u -p -r1.43 main.c
> --- main.c 29 Mar 2018 20:22:05 -0000 1.43
> +++ main.c 28 Jul 2018 18:48:15 -0000
> @@ -2782,12 +2782,12 @@ main(int argc, char *argv[]ENVP_ARG)
> if (data &&
> (strstr(data, "exec-formatted") || strstr(data,
> "exec-selectable"))) {
>
> - if (pledge("stdio rpath wpath id proc exec tty", NULL) == -1) {
> + if (pledge("stdio rpath cpath wpath id proc exec tty", NULL) ==
> -1) {
> xtermWarning("pledge\n");
> exit(1);
> }
> } else {
> - if (pledge("stdio rpath wpath id proc tty", NULL) == -1) {
> + if (pledge("stdio rpath cpath wpath id proc tty", NULL) == -1) {
> xtermWarning("pledge\n");
> exit(1);
> }
>
