James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: > On Tue, 2017-02-14 at 20:46 +1300, Eric W. Biederman wrote: >> James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: >> >> > Now that we have two different views of filesystem ids (the >> > filesystem view and the kernel view), we have a problem in that >> > current_fsuid/fsgid() return the kernel view but are sometimes used >> > in filesystem code where the filesystem view shoud be used. This >> > patch introduces helpers to produce the filesystem view of current >> > fsuid and fsgid. >> >> If I am reading this right what we are seeing is that xfs explicitly >> opted out of type safety with predictable results. Accidentally >> confusing kuids and uids, which is potentially security issue. >> >> All of that said where are you getting sb->s_user_ns != &init_user_ns >> for an xfs filesystem? James please answer this question: Where are you getting sb->s_user_ns != &init_user_ns for an xfs filesystem? None of this matters if sb->s_user_ns == &init_user_ns. This is signification because only xfs keeps any in-core data structure in it's on-disk encoding. So this problem is xfs specific. So understanding how you are getting xfs to have sb->s_user_ns != &init_user_ns is important for discussing which direction we go with helper functions here. xfs with sb->s_user_ns == &init_user_ns is perfectly fine and as such no fixes are needed. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
