2016-09-03 11:04 GMT+02:00 Luke Small <lukensm...@gmail.com>: > > > Sorry I was in the middle of something, but pledge can be a broad brush, > unless you are dealing with one file, whether it is executed, read, or > written and giving per process file permissions sounds pretty neat, and it > might just be a little simpler than making new users for each subset of > privileges, populating each chrooted home folder with a specific set of > permissions (as is what appears to me to have happened with pkg_add). Since > pledge's promises can make it where you can execute a file without read > permission, it seems ideal to continue that tradition with the paths > > On Sat, Sep 3, 2016, 03:07 Luke Small <lukensm...@gmail.com> wrote: >> >> In pledge, presumably there will be an accessible paths list. Maybe you >> grant a process root access, and you need to read a file which is only >> granted by root access, and you need write access for another file, so the >> pledge permissions reflect that. On the presumed current path, you would >> leave write access for the first file and maybe you don't need the process >> to have read permissions on an execl() program. You can prohibit your >> process from reading your software or binary, even if it may have >> permissions to do so. >>
That's not a specific use case. Either you should provide a patch or an exemple of a real program that is limited by the current design of pledge. Currently, if you want a program that can only read a file, you pledge rpath. If you want the ability to exec file, you pledge exec. If you want a program that can exec a set of file and write in another, either you run your program as a user and group that can't write the set of file you want to exec (W^X) or you write two program, one pledging for write the other for read. There following paper have an exemple of how the second design can be done. http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html -- Cordialement, Coues Ludovic +336 148 743 42
