About security_path_mknod() in aufs.

[Tim Gardner]

On 11/09/2010 04:58 AM, Tetsuo Handa wrote:
> Hello.
>
> TOMOYO has started to check 'dev' argument of security_path_mknod() since
> 2.6.36. The argument 'dev' is passed without new_decode_dev() conversion.
>
> This is because I thought we should avoid useless new_decode_dev() call if
> LSM modules (i.e. SELinux/Smack/AppArmor) don't check that argument.
> I expected that security_path_mknod() is called from places outside vfs_mknod().
>
> 2016         error = security_path_mknod(&nd.path, dentry, mode, dev);
> 2017         if (error)
> 2018                 goto out_drop_write;
> 2019         switch (mode&  S_IFMT) {
> 2020                 case 0: case S_IFREG:
> 2021                         error = vfs_create(nd.path.dentry->d_inode,dentry,mode,&nd);
> 2022                         break;
> 2023                 case S_IFCHR: case S_IFBLK:
> 2024                         error = vfs_mknod(nd.path.dentry->d_inode,dentry,mode,
> 2025                                         new_decode_dev(dev));
>
> But aufs's vfsub_mknod() (called from add_simple() from aufs_mknod() from
> vfs_mknod()) is calling security_path_mknod().
>
>   266 int vfsub_mknod(struct inode *dir, struct path *path, int mode, dev_t dev)
>   267 {
>   268         int err;
>   269         struct dentry *d;
>   270
>   271         IMustLock(dir);
>   272
>   273         d = path->dentry;
>   274         path->dentry = d->d_parent;
>   275         err = security_path_mknod(path, d, mode, dev);
>   276         path->dentry = d;
>   277         if (unlikely(err))
>   278                 goto out;
>   279
>   280         err = vfs_mknod(dir, path->dentry, mode, dev);
>
> In vfsub_mknod(), 'dev' was already converted by 'new_decode_dev(dev)'
> but TOMOYO is expecting 'dev' rather than 'new_decode_dev(dev)'.
>
> With Natty kernel, TOMOYO will check new_decode_dev(new_decode_dev(dev))
> (which is wrong) when security_path_mknod() is called from vfsub_mknod().
>
> How should we fix this?
>
> Regards.
>

John - any comments?

-- 
Tim Gardner tim.gardner at canonical.com