Re: [PATCH 7/8] ima: remove usage of filename parameter

[Mimi Zohar]

On Wed, 2014-09-03 at 16:28 +0300, Dmitry Kasatkin wrote: 
> On 03/09/14 16:16, Mimi Zohar wrote:
> > On Wed, 2014-09-03 at 10:20 +0300, Dmitry Kasatkin wrote: 
> >> In all cases except ima_bprm_check() filename was not defined and
> >> ima_d_path() was used to find full path.
> >>
> >> ima_bprm_check() used to select between bprm->interp and bprm->filename.
> >> Following dump demonstrates differences between using filename and interp.
> >>
> >> bprm->filename
> >>  filename: ./foo.sh, pathname: /root/bin/foo.sh
> >>  filename: ./foo.sh, pathname: /bin/dash
> >>
> >> bprm->interp
> >>  filename: ./foo.sh, pathname: /root/bin/foo.sh
> >>  filename: /bin/sh, pathname: /bin/dash
> >>
> >> In both cases pathnames are the same.
> >> This patch removes usage of filename and interp in favor of d_path.
> >>
> >> Signed-off-by: Dmitry Kasatkin <d.kasatkin@xxxxxxxxxxx>
> > Thanks, this has been on my list to do.  My only concern is whether we
> > should be using d_path() or one of the other variants (eg.
> > dentry_path(), d_absolute_path()).  For namespaces, we would want to be
> > able to differentiate the files.
> >
> > Please include in this patch description why d_path(), if it is the
> > case, the best option.
> >
> > thanks,
> 
> Hi,
> 
> Actually as we discussed, we can also in this patch change ima_d_path to
> use d_absolute_path().
> It will work for "chroot" cases and will show real path...
> 
> Should I switch to 'd_absolute_path'?

Yes, please.

> In the case of namespaces, neither d_path nor d_absolute_path works....
> Usage of dentry_path() would eliminate mount tree and requires device
> prefix.
> But it will 'break' clients, reading process measurement list.
> That would require essentially more agreement.

Right, we shouldn't break anything, but define a new template field for
the device or some other info.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/