Hi,
First, thanks to (trying) to search for solve the problem you encountered.
On Sat, Jul 28, 2018 at 10:08:04PM +0300, Leonid Bobrov wrote:
> Hi!
>
> 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);
>
your search isn't accurate regarding the error message you got.
the pledge error in dmesg could be read as:
xterm (pid 90461) has been killed due to pledge violation.
the program tried to use syscall 5 using "cpath" promise, but it
didn't pledged for it.
what is the syscall 5 ?
$ grep ' 5$' /usr/include/sys/syscall.h
#define SYS_open 5
So it is an open(2) call which need "cpath".
if it needs "cpath", the flags argument of open(2) should contains
O_CREAT:
kern/vfs_syscalls.c
1018 if (oflags & O_CREAT)
1019 ni_pledge |= PLEDGE_CPATH;
so at some point after calling pledge(2), xterm called open(?, ?|O_CREAT).
it could be a direct call to open(2), or an indirect call (like calling
fopen(3) with "w").
if you search in xterm code source, you should find several occurrences
of such calls. But like deraadt@ told you, you should also ensure this
call is effectively *after* the pledge call.
as hint, you know it seems to be triggerable from some keyboard
combinaison. enumerating what xterm does by default for such things
could help too to track the problem.
there is a open(2) call somewhere: the pledge violation is proof of
that. but the solution isn't necessary to allow this file creation (by
bindly extending the pledge promises). it could be to disallow the file
creation.
but to decide, we should know *what* triggered this behaviour.
personally, I like to know that xterm is unable to create a file.
thanks.
--
Sebastien Marie
