All of lore.kernel.org
 help / color / mirror / Atom feed
From: Subodh Nijsure <snijsure@grid-net.com>
To: mtd <linux-mtd@lists.infradead.org>
Subject: Setting security XATTR on ubifs
Date: Fri, 20 May 2011 16:36:41 -0700	[thread overview]
Message-ID: <1305934601.10340.12.camel@subodh-desktop> (raw)


we have implemented modifications to UBIFS to add support for SELinux
labeling. Function that created this XATTR is called
ubifs_init_security(), shown below.

Following example of how JFFS2 does extended attribute labeling, This
function is being called from 
ubifs_create(),ubifs_mkdir(), ubifs_mknod(), ubifs_symlink() (in
fs/ubifs/dir.c)

With this modification things work "mostly", I am able to label the file
system, but sometimes the file system is getting corrupted. I will
certainly post the patch once things work reliably. 

I don't _fully_ understand how ubifs is doing space management, hence
the immediate questions I have are:
1. What is the right point to add the XATTR to the UBIFS inode, after
the ubifs_new_inode() is done? Should ubifs_budget_space() be updated to
handle extra space needed by the XATTR.

2. In function below ui_mutex is being locked/unlocked while XATTR for
the file is updated. Is that required while updating the extended
attribute?

-Subodh Nijsure

static void ubifs_init_security(struct dentry *dentry, struct inode
*inode, struct inode *dir)
{
        int err;
        char *name;
        void *value = NULL;
        size_t len = 0;
        struct ubifs_inode *dir_ui = ubifs_inode(dir);
        mutex_lock(&dir_ui->ui_mutex);
        err = security_inode_init_security(inode, dir, &name, &value,
&len);
        if (err) {
                if (err == -EOPNOTSUPP)
                        return;
                ubifs_err("unable to retrieve security context, error %
d", err);
                mutex_unlock(&dir_ui->ui_mutex);
                return;
        }
        err = ubifs_setxattr(dentry, name, value, len, 0);
        if (err)
                ubifs_err("unable to set security context (extended
attribute), err %d",err);
        kfree(name);
        if ( value )
                kfree(value);
        mutex_unlock(&dir_ui->ui_mutex);
}

             reply	other threads:[~2011-05-20 23:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20 23:36 Subodh Nijsure [this message]
2011-05-23 14:57 ` Setting security XATTR on ubifs Artem Bityutskiy
     [not found]   ` <C7A5B00EFC707A46AB67997D02152167010F582C@mx1.grid-net.com>
2011-05-30  9:12     ` Artem Bityutskiy
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=1305934601.10340.12.camel@subodh-desktop \
    --to=snijsure@grid-net.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.