On Fri, Nov 14, 2008 at 11:21 AM,  <casper....@sun.com> wrote:
>
>>On Thu, Nov 13, 2008 at 3:05 AM,  <casper....@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.
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to