linux-kernel - security_inode_init_security() inode field requirements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1362132778.2723.15.camel@menhir>
Date:	Fri, 01 Mar 2013 10:12:57 +0000
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Mimi Zohar <zohar@...ibm.com>, Chris Wright <chrisw@...s-sol.org>,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, cluster-devel@...hat.com,
	linux-kernel@...r.kernel.org
Subject: security_inode_init_security() inode field requirements

Hi,

I'm wondering whether there is a list somewhere of fields which
security_inode_init_security() requires are set in an inode when it is
called? In particular, does it matter if the inode number itself is
unset when security_inode_init_security() is called?

The problem that I'm looking at is the use of multiple transactions
during inode creation when some combination of ACLs/LSMs/IMA are turned
on. What we have currently (in GFS2, there are other fs which follow
broadly the same solution though) is this:

1. Create inode in core
2. Create inode on disk
3. Add xattrs one at a time for ACLs/LSMs/IMA
4. Link inode into directory

Steps 2 through 4 require separate transactions at the moment. What I'd
like to do is to be able to get the details of the xattrs ahead of time
such that the allocation of the inode can be one and the same allocation
as that for the xattr blocks. That allows merging of the transactions
into one and a greatly simplified error path too. This would look
something like:

1. Create in-core inode and init required fields
2. Get details of all xattrs for the inode
3. Alloc on disk inode and blocks for xattrs as needed
4. Link into directory

In this case, steps 2 through 4 are within a single transaction. We
don't actually need to have the content of the xattrs ahead of
allocating the inode, just the length (or even just a max length, if it
is not too large). However the easiest solution would just be to move
the call to security_inode_init_security() to the point before we've
allocated the inode (and thus we don't know its number yet) but after
we've filled out all the remaining fields if that makes sense?

So I just wanted to check whether that would break anything,

Steve.

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