All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Subodh Nijsure <snijsure@grid-net.com>
Cc: mtd <linux-mtd@lists.infradead.org>
Subject: RE: Setting security XATTR on ubifs
Date: Mon, 30 May 2011 12:12:24 +0300	[thread overview]
Message-ID: <1306746744.4405.22.camel@localhost> (raw)
In-Reply-To: <C7A5B00EFC707A46AB67997D02152167010F582C@mx1.grid-net.com>

On Fri, 2011-05-27 at 06:08 -0700, Subodh Nijsure wrote:
> Yup I did run UBIFS with debug & extra checks and discovered few issues.
> Found that setxattr/getxattr require that we should have already taken
> host->i_mutex. So I have updated my ubifs_init_security() accordingly.

Great!

> One of the problem turned out to be in change_xattr function, ui->data_len
> was updated at wrong place, and hence when after unmount, mount the
> length of the XATTR was wrong. I test
> 
> Diff below fixes that immediate issue. I tested this with
> As I mentioned, will post entire patch that allows ubifs to work with
> SELinux by end of this week.
> 
> diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
> index 3299f46..a413278 100644
> --- a/fs/ubifs/xattr.c
> +++ b/fs/ubifs/xattr.c
> @@ -211,11 +211,11 @@ static int change_xattr(struct ubifs_info *c,
> struct inode *host,
>         }
>         memcpy(ui->data, value, size);
>         inode->i_size = ui->ui_size = size;
> -       ui->data_len = size;
> 
>         mutex_lock(&host_ui->ui_mutex);
>         host->i_ctime = ubifs_current_time(host);
>         host_ui->xattr_size -= CALC_XATTR_BYTES(ui->data_len);
> +       ui->data_len = size;
>         host_ui->xattr_size += CALC_XATTR_BYTES(size);

Could you please submit a separate patch for this with

Cc: stable@kernel.org

> Now I am looking at much bigger issue where, if I create char device
> and assign it XATTR, on umount the file system is getting marked
> corrupted. This is with testing on NANDSIM, it happens on actual HW
> too. It appears that node_scan doesn't seem to be reading XATTR data
> and accounting for it when computing checksum.

If you send me a test program I might look at this, but no promises.
Thanks!

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  parent reply	other threads:[~2011-05-30  9:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20 23:36 Setting security XATTR on ubifs Subodh Nijsure
2011-05-23 14:57 ` Artem Bityutskiy
     [not found]   ` <C7A5B00EFC707A46AB67997D02152167010F582C@mx1.grid-net.com>
2011-05-30  9:12     ` Artem Bityutskiy [this message]
2011-06-07 11:07       ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1306746744.4405.22.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=snijsure@grid-net.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.