Hi, Theo Buehler wrote on Sun, Apr 10, 2016 at 01:43:17PM +0200:
> This is a first stab at updating the list of syscalls in the pledge(2) > manpage and at the same time I'd like to clarify some simple things. I sympathise a lot with the idea to make this page as accurate as possible. To me, that seems the only way to help programmers to use pledge(2) correctly and avoid both unnecessary pledges and unpleasant runtime surprises. It is probably harder to describe pledge(2) exhaustively than to describe most other functionality, and it may sometimes be required to skip unusually arcane details to avoid making the manual unreadable. But given that the intended audience of this manual is advanced programmers, i'd rather lean towards precision than towards simplicity in cases of doubt. I can't provide feedback for all the syscalls you ask about, and i'll simply skip those that i don't know sufficiently well to comment. Also, i don't feel confident enough to read the pledge(2) kernel code correctly to provide a proper OK, but i trust you as far as getting the content of such a diff correct is concerned. > I'm wondering about the chflags(2), chown(2) and chmod(2) families of > system calls. They are currently listed up to four times: once at the > beginning where it is explained that they have general restrictions, > which makes sense. Then they are also listed under "fattr", "rpath" and > "wpath". Wouldn't "fattr" with a corresponding note about possible > additional need for "rpath" and "wpath" be better? > > The following aren't listed in the manpage. Should some of them be? > > [SYS_sendsyslog] = PLEDGE_ALWAYS, /* stack protector reporting */ It looks like that's already listed below "stdio". By the way, since sendsyslog(2) is only intended to be called by syslog(3) and not directly by application code, i'd prefer to have syslog(3) listed instead of sendsyslog(2) - but that's probably a seperate matter. > [SYS_osendsyslog] = PLEDGE_ALWAYS, /* obsolete sendsyslog */ Don't list that one. It will go away soon, and no application program can reasonably use it. > [SYS_thrkill] = PLEDGE_ALWAYS, /* raise, abort, stack pro */ Looks like that should be listed; or maybe - like for syslog, since this is hardly fit for direct use - pthread_kill(3), raise(3), abort(3) instead? > [SYS_utrace] = PLEDGE_ALWAYS, /* ltrace(1) from ld.so */ Looks like it should be listed. > The kill(2) call is only mentioned under "proc". The special case of > "killing self" currently isn't mentioned and probably should be: I agree, that seems important. > /* > * Can kill self with "stdio". Killing another pid > * requires "proc" > */ > [SYS_o58_kill] = PLEDGE_STDIO, But of course, don't mention o58_kill, which will go away. > [SYS_kill] = PLEDGE_STDIO, > > What about this one? It is not currently mentioned at all. > /* > * Classify as RPATH|WPATH, because of path information leakage. > * WPATH due to unknown use of mk*temp(3) on non-/tmp paths.. > */ > [SYS___getcwd] = PLEDGE_RPATH | PLEDGE_WPATH, That's a very clear case of a function that should never be called directly. We don't even have a manual page for it, and none is needed. The __getcwd(2) syscall is intended to be only called by getcwd(3), and that is correctly listed below both "rpath" and "wpath", so nothing to do here. > Index: pledge.2 > =================================================================== > RCS file: /var/cvs/src/lib/libc/sys/pledge.2,v > retrieving revision 1.27 > diff -u -p -r1.27 pledge.2 > --- pledge.2 11 Mar 2016 06:36:51 -0000 1.27 > +++ pledge.2 10 Apr 2016 10:26:25 -0000 > @@ -133,6 +134,7 @@ The following system calls are permitted > in libc, including memory allocation, most types of IO operations on > previously allocated file descriptors: > .Pp > +.Xr break 2 , That's brk(2), not break(2) - different name of syscall and C library function, and the manual is named after the C library function. The name of the manual page was changed going from AT&T Version 6 UNIX to AT&T Version 7 UNIX, the latter released in 1979, so you are slightly out of date here, by about 37 years and 3 months... =;-) Yours, Ingo
