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