On Sun, Jul 29, 2018 at 07:28:19AM +0200, Sebastien Marie wrote: > 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.
Hi, After digging a bit, there is at least the 'Print All Immediatly' function from button 1 menu that will trigger the creation of a file and violate the pledge. see xtermPrintImmediately() in print.c:789. The fopen() itself appears in charToPrinter() on line 498 of the same file. Should this feature be disabled in xterm ? -- Matthieu Herrb