On Fri, Nov 14, 2008 at 11:21 AM, <Casper.Dik at sun.com> wrote: > >>On Thu, Nov 13, 2008 at 3:05 AM, <Casper.Dik at sun.com> wrote: >>> >>> >>>>Originally I did that, but there was concern v_path might not always >>>>be correct (or available) (such as renames or with hard links IIRC), >>>>and so might generate a confusing message in those situations. I >>>>wasn't aware of any mechanism that could take exec_file or the vnode >>>>and generate a nice canonical pathname that didn't suffer from >>>>renaming or hard link issues, so the mountpoint was chosen instead. I >>>>think ideally it'd be nice to have both (in case the offending binary >>>>is deleted, you can still figure out where it took place). >>> >>> There are a few renamings we need to fix in the fs code; there's code >>> which interprets v_path and beautifies like we use for /proc. >>> >>> Then you either get proper path or no answer. Typically, though, >>> because your inside exec you MUST have translated the pathname. >> >>Doing a little digging through the /proc code a few minutes ago, does >>this mean you're suggesting using vnodetopath() ( >>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/lookup.c#vnodetopath >>) and using that if it returns a non-NULL value (which it sounds like >>it always should)? > > > I don't think there's a 100% guarantee, but I can't of the top of my head > see where it not work. I would, however, make sure that you handle a > failure of the function. > > Casper > >
Reviving things (now that I have a bit more time), http://cr.opensolaris.org/~jbk/suid has the updated changes. I'm not sure how to force a failure of vnodetopath() to test that code path, but aside from that everything tested ok. For full disclosure, I've only tested this on x86 (no sparc boxes I can touch to test on there). It was tested both in and outside of a zone.
