Re: New sysctl entry: proc.PID.realpath

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Le 15/09/2015 23:17, Kamil Rytarowski a écrit :
> On 07.09.2015 17:58, Jean-Yves Migeon wrote:
>> Hello there,
> 
>> Le 2015-09-07 12:24, Kamil Rytarowski a écrit :
>>> I'm here to get the support for it. At the moment it (cache nits)
>>> exceeds my comprehension too.
>>>
>>> Are the other bits ok? KAUTH usage,
> 
>> I wouldn't create an action/subaction (AUTH_PROCESS_REALPATH and 
>> KAUTH_REQ_PROCESS_REALPATH_GET) specifically for this sysctl. I 
>> think you could get this information through other code paths 
>> combined with find(1) (like fstat(1)ing the process and find the 
>> dev/inode associated with "text"). Adding access restrictions to 
>> this sysctl means you have to kauth-audit the other paths too.
> 
> Do you mean that if a user can access (fstat(1)) a file, then should
> see its entry in the exec pathname in this sysctl(7)?

Nope. AFAICT, under other BSD (FreeBSD if memory serves right), fstat(1)
a process will return a line with a FD of type "text", which usually
points to the vnode referencing the exec'ed binary.

Our fstat(1) seems to allow for the printing of a such a FD too [1]. As
there is KVM magic at work here, I was merely suggesting that this
information (the vnode ref) is probably accessible somewhere, but this
path will not necessarily be protected by the kauth action you were
adding when accessed via sysctl(3).

[1] http://nxr.netbsd.org/xref/src/usr.bin/fstat/fstat.c#410

> I was follow the rules of corename here.

Sure.

>>> colonization kern_resource.c etc.
> 
>> Shouldn't it be in kern_proc.c?
> 
> 
> Perhaps yes, I was inspired by corename here too.
> 
> Thanks!

You're welcome :)

-- 
Jean-Yves Migeon