Re: Heed help: Calling sys_getcwd to resolve relative pathnames from within systemtap

[Sebastian Pipping <sebastian at pipping dot org>]

On 09/30/2011 02:53 AM, Josh Stone wrote:
> The syscall is going to expect the buffer to be a userspace pointer, so
> I don't think that will work.  Besides, sys_getcwd is not an exported
> function, so it can't be called from modules.

I see - that explains the link error on sys_getcwd that I got.

> 
>> However, I fail to call sys_getcwd, even from pure blocks like
>>
>>    %{ /* pure */ /* unprivileged */
>>      [..]
>>    %}
> 
> You left out all the interesting bits!  Please, if you want help
> diagnosing your efforts, we need the details of what you tried.

Okay.


> 
> But just to clarify on the two annotations you put in there:
> 
> /* pure */ means that this block has no side effects apart from the
> returned value.  So if our optimizer decides the value isn't needed, we
> can remove this altogether.  That's probably appropriate here.
> 
> /* unprivileged */ means that restricted users running as their script
> under stap --unprivileged are allowed to call this function.  That's
> almost certainly not the case here, because to even put this in your
> script you must be in guru mode already.  This is mainly intended for
> tapset functions, and only after careful security consideration.

Thanks for these details!


> I'm not sure there's an easy way in general.  From a slightly different
> part of the open callchain though, there are better variables available.
>  I found that this works:
> 
> probe kernel.function("do_filp_open").return {
>     if (errno_p($return)) {
>         printf("%5d %5d %-16s %s %s\n",
>                pid(), tid(), execname(), errno_str($return),
>                kernel_string($pathname))
>     } else {
>         file = task_dentry_path(task_current(),
>                                 $return->f_path->dentry,
>                                 $return->f_path->mnt)
>         printf("%5d %5d %-16s opened %s\n",
>                pid(), tid(), execname(), file)
>     }
> }
> 
> That only works for the successes though, and for failures it's still
> printing a relative name.  I hope that's still helpful to you...

As I am mostly interested in the working names, it is in fact quite
helful - thanks!

Best,



Sebastian