tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New sysctl entry: proc.PID.realpath
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
Home |
Main Index |
Thread Index |
Old Index