[lkml]   [2012]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [rfc] fcntl: Add F_GETOWNER_UIDS option
    On Fri, Mar 30, 2012 at 9:15 AM, Serge E. Hallyn <> wrote:
    > Quoting Cyrill Gorcunov (
    >> On Fri, Mar 30, 2012 at 09:12:19AM -0500, Serge Hallyn wrote:
    >> ...
    >> > >
    >> > > Yes, I wanna take a look on Eric's set first just to get right
    >> > > "picture" of everything. And I wanted to find a minimal solution
    >> > > with current kernel code base which could be extended in future.
    >> > >
    >> > > That said I guess the current init-ns-only approach should do the
    >> > > trick for a while. And (thanks for pointing) I need to add a test
    >> > > if a caller which tries to obtain uids has enought credentials
    >> > > for that (probably CAP_FOWNER), right?
    >> >
    >> > Sorry, I'm not sure which caller you mean.  Neither f_setown nor
    >> > f_getown require privilege right now.  Oh, you mean at restart?
    >> I meant the dumper. Yes, at moment f_get/setown requires no privileges
    >> but I'm not sure if uid/euid is same or less sensible information
    >> than pid, that's why I though CAP_FOWNER might be worth to add, no?
    > Hmm, I would say no, but that might be a good question for kees.
    > IMO it's not sensitive information and so no sense requiring privilege
    > (and encouraging handing out of extra privilage to get at the info)

    Nothing jumps out at me about just seeing uid/euid. Everything can be
    construed as an information leak, but this don't seem like something
    that needs special protection.


    Kees Cook
    ChromeOS Security
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-03-30 21:49    [W:0.022 / U:31.400 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site