Re: New sysctl entry: proc.PID.realpath

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

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.

> colonization kern_resource.c etc.

Shouldn't it be in kern_proc.c?

> > > We then should also make $ORIGIN work in ld.elf_so ;-}
>
> It's scheduled.

Good :)

Le 2015-09-07 11:13, Joerg Sonnenberger a écrit :
> My suggestion was to just provide the filesystem id and inode number as
> fallback. I still believe we should just turn on the code that 
> remembers
> the realpath on exec in first place, if you want to debug
> something_with_a_very_very_very_very_..._very_long_name, you can always
> override the (missing) default.

I suggest that the semantic to be clarified like Robert suggested first, 
so there is no ambiguity. FWIW under Linux, when you are readlinking the 
fd paths under /proc, opened-then-deleted files have their linkpaths 
containing "[...] (deleted)", which is counterintuitive when the files 
gets opened/worked on/deleted by multiple scripts. In that case I'd 
prefer having the dev/inode indicated instead.

Cheers,

--
Jean-Yves Migeon