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.kasat...@samsung.com> > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
