Hi Theo > interesting. Yes, msyscall() should probably be in the "stdio" set. > > But I've been considering deleting execpromises. It was put in as an > experiment, and I tried to make code in the base use it. I was unable > to find great usage cases, and so I am considering deleting it.
Looking at my code, I noticed that pledge(), is always one of the first functions called, maybe I'm doing it wrong, but I tend to call pledge() more than once during the lifetime of a command. I think the execpromises, in my specific case, doesn't make much sense because one of the first thing I do after a fork+exec, is to call pledge() on the new program. I tried to use it because it is there, but I agree that, after checking my code, it's not that useful at all. > Andrea Biscuola <a...@abiscuola.com> wrote: > > > Hi @misc > > > > It appear the introduction of msyscall(2), broke the existing code > > of one of my projects. > > > > My code use a fork+exec model for executing different commands > > and pledge(2) is used for restricting the behavior of the child > > process using the execpromises argument. > > > > The problem is that, when a child process that was forked with > > the execpromises argument set load a new program, the process > > is killed because msyscall(2) is not permitted by the parent pledge(2). > > > > I checked in the /usr/src/sys/kern/kern_pledge.c file and it appear > > the msyscall(2) system call is not added to any category yet, thus > > not allowing me to use the execpromises argument for now. > > > > At the moment, I solved the problem by setting the execpromises > > for the pledge(2) calls to NULL. > > > > Is this expected? It's not really a problem as I'm running current > > and I know things could break and the workaround is ok (all the > > commands uses pledge(2) anyway). Is there some more work in > > progress that will solve the situation during the development > > cycle? > > > > Thank you and regards. > > -- > > Andrea > > > -- Andrea
