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

Reply via email to