On 06/18/2015 11:32 AM, David Howells wrote:
> Stephen Smalley <s...@tycho.nsa.gov> wrote:
> 
>>> Fair point.  What does SBLABEL_MNT mean precisely?  It seems to indicate one
>>> of an odd mix of behaviours.  I presume it means that we *have* to 
>>> calculate a
>>> label and can't get one from the underlying fs if it is not set.
>>
>> It means the filesystem supports per-file labeling and you can use
>> setxattr(..."security.selinux") and setfscreatecon() for files on it.
>> You can see whether it is set on a filesystem by looking for the
>> seclabel option in cat /proc/mounts.  If it is not set, then we ignore
>> tsec->create_sid.  It is arguable as to whether it is correct to always
>> call security_transition_sid() there either, but that's another topic.
> 
> Okay, so how about the attached?
> 
> David
> ---
> static int selinux_determine_inode_label(const struct inode *dir,
>                                        const struct qstr *name,
>                                        const char *caller,
>                                        u16 tclass,
>                                        u32 *_new_isid)
> {
>       const struct superblock_security_struct *sbsec = dir->i_sb->s_security;
>       const struct inode_security_struct *dsec = dir->i_security;
>       const struct task_security_struct *tsec = current_security();
> 
>       if ((sbsec->flags & SE_SBINITIALIZED) &&
>           (sbsec->behavior == SECURITY_FS_USE_MNTPOINT)) {
>               *_new_isid = sbsec->mntpoint_sid;
>       } else if ((sbsec->flags & SBLABEL_MNT) &&
>                  tsec->create_sid) {
>               *_new_isid = tsec->create_sid;
>       } else {
>               return security_transition_sid(tsec->sid, dsec->sid, tclass,
>                                              name, _new_isid);
>       }
> 
>       return 0;
> }

Except you can drop the caller argument now.


--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to