Anton Lindqvist <an...@openbsd.org> wrote: > On Thu, Mar 11, 2021 at 11:12:41AM -0700, Klemens Nanni wrote: > > CVSROOT: /cvs > > Module name: src > > Changes by: k...@cvs.openbsd.org 2021/03/11 11:12:41 > > > > Modified files: > > usr.sbin/apmd : apmd.c > > > > Log message: > > Use unveil(2) > > > > Pledge is not possible due to the ioctls, but as apmd hoists both the > > control socket and apm device early at startup and only ever possibly > > executes scripts under /etc/apm/, hiding the rest of the filesystem > > becomes easy. > > > > Technically, only "x" is required to traverse the directory and run > > scripts, but apmd carefully access(2) each script, which requires > > the read bit regardless of the permission bits being tested. > > > > OK mestre > > > > System accounting started to report unveil violations after this commit: > > Purging accounting records: > apmd -FU root __ 0.06 > secs Mon Mar 15 00:15 (8:59:20.00) > > This is what ktrace shows: > > 71448 apmd CALL access(0x66348711fa,0x5<X_OK|R_OK>) > 71448 apmd NAMI "/etc/apm/resume" > 71448 apmd RET access -1 errno 2 No such file or directory > 71448 apmd CALL write(2,0x7f7ffffcf630,0x31) > 71448 apmd GIO fd 2 wrote 49 bytes > "do_etc_file(): cannot access file /etc/apm/resume" > > Only /etc/apm/suspend is present on this machine.
"/etc/apm" directory is unveiled for "rx" I think the kernel is creating an AUNVEIL record incorrectly. kern_unveil.c 969 might be incorrect, the ENOENT fallthru is not a failure to find an unveil match, but an actual file missing sitaution. If that line is deleted, I bet it helps. But is it correct?
