Garrett D'Amore wrote: > Rainer Orth wrote: > > "Richard L. Hamilton" <rlha...@smart.net> writes: > > > > > >> Unless someone snuck it in when I wasn't looking, > this has been > >> missing for ages - /proc does not reveal the umask > of a process. > >> Sometimes that would be interesting. > >> > >> Both psinfo_t and pstatus_t have at least one > int's worth of pr_filler, > >> so there's a place to put it if one wanted to > (which it should go in > >> perhaps depending on whether one wished to conceal > it given the different > >> permissions?). And aside from the header file, I > gather it would take all of > >> oh, about one more line of code in prsubr.c. > >> > >> I whipped up a "pumask" command that would report > the umask of a process > >> using libkvm, but that's generally an evil thing > to have to use. (I think it > >> would work on a crash dump too, given that it > takes command line options > >> for namelist, corefile, swapfile; but I'm not so > sure how to dig the info out > >> of a plain old core dump, which might be more > typical of the p* commands.) > >> > > > > True: there's a long-standing RFE for this feature: > > > > 5003454 RFE: provide pumask > > > > I'm not entirely confident of the security > implications of publishing > this (it "seems" like it should be safe, but I'm not > sure). However, > I'd be happy to sponsor a fast track to make this > change if you decide > that's what you want to do.
As I'd said, depending on whether one added it to an unused field of pstatus_t (/proc/*/status - readable only by owner) or psinfo_t (/proc/*/psinfo - publically readable) would determine whether anyone or only someone with the ability to read any file could see this. I suppose one might wish to hide it on the premise that a hostile might prefer to look for files being created by processes with a permissive umask (022, or worse, 000). Or alternatively, that only someone who could legitimately obtain sufficient privileges should need to know that info about any processes other than their own. In which case, that should be added to pstatus_t (assuming one wants to add it to an existing structure compatibly rather than creating a new one just for that). Then it seems reasonable to change int pr_filler[15]; to mode_t pr_cmask; /* file creation mask */ int pr_filler[14]; which leaves the layout unaffected (in either 32-bit or 64-bit, since mode_t is 32-bit in both). Then one would have to add to prgetstatus() in prsubr.c something like sp->pr_cmask = p->p_user.u_cmask; although for the benefit of a new pumask tool (which could presumably also examine core files, which I think record prstatus_t already), one might mask the value down to just the bits actually applicable to a umask and then OR it with a magic number that goes in the other bits, so that pumask could distinguish a core file without a umask from one with a umask. Finally, the new pumask tool could be modeled on whichever of the ptools is simplest (least to rip out) that looks at pstatus_t and can handle both live processes and core files. I could maybe code all this, but I am not set up to do builds, and to attempt that at all (let alone on the test farm), I'd need a _lot_ of handholding. Perhaps I'm just whining for someone with more patience, experience, time, and a longer attention span than mine to take over the less pleasant bits of getting otherwise more or less straightforward changes made. -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
