Amerigo Wang <amwang@xxxxxxxxxx> writes: > OGAWA Hirofumi wrote: >> Eric Paris <eparis@xxxxxxxxxx> writes: >> >> >>>>> I was thinking about this and kept telling myself I was going to test v2 >>>>> before I ack/nak. Clearly we shouldn't for the dropping of SUID if the >>>>> process didn't have permission to change the ATTR_SIZE. >>>>> >>>>> Acked-by: Eric Paris <eparis@xxxxxxxxxx> >>>>> >>>> BTW, Do you know why doesn't security modules fix the handling of >>>> do_truncate() (i.e. ATTR_MODE | ATTR_SIZE). And why doesn't it allow to >>>> pass ATTR_FORCE for it? >>>> >>> I'm not sure what you mean. I understood ATTR_FORCE to mean 'I am magic >>> and get to override all security checks." Which is why nothing should >>> ever be using ATTR_FORCE with things other than SUID. >>> >>> I guess we could somehow force logic into the LSM to make it only apply >>> to SUID and friends but I'm not sure it buys us anything. >>> >> >> Yes, I think it's good way. Don't we want to do the following? >> >> if (permission check of job) >> return error; >> if (do job at once) >> return error; >> >> But currently way is, >> >> if (permission check of first part) >> return error >> if (do first part of job) >> return error >> if (permission check of second part) >> return error >> if (do second part of job) >> return error >> >> So, if second part was error, we may want to undo the job of first part >> in theory. But, to undo is just hard and strange. >> > > Yeah, the problem is currently we don't have such wrappers, only > notify_change(). :-/ I'm not sure you are meaning what wrappers though, I'm still thinking changing LSM (or something) like Eric said is the way to do it easily (and define ATTR_FORCE is not for ATTR_SIZE at least). Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
