--- Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > On Fri, 2008-03-07 at 10:14 -0800, Casey Schaufler wrote: > > --- Dave Quigley <dpquigl@xxxxxxxxxxxxx> wrote: > > > > > For some odd reason I can't quite parse the first two parts > > > > Let me try a different angle on the question. Maybe it just > > doesn't come up as a real issue, and I'm concerned about nothing. > > > > Just for grins lets say I wanted to set the secctx on a directory > > in a derivative of ramfs in some unspecified way that is not > > related to mkdir. There are no on-disk inodes. Should the code call > > inode_setsecctx, inode_notifysecctx, or both? It seems rational to > > me to call inode_setsecctx, but since the differentiation between > > the interfaces is the "on disk" factor and ramfs only exists as > > in core, it would seem that inode_notifysecctx would be correct. > > If you are setting (changing) the value, then use inode_setsecctx (or > the existing inode_setsecurity, which is used by the xattr code, but > that is limited to setting a single xattr value by name). So any code that wants to explicitly set the secctx (as opposed to a specific attribute value) calls inode_setsecctx. This makes perfect sense. > If you are just notifying the security module of a value that should be > associated with the inode, use inode_notifysecctx. So this is a way for filesystem code to pass information to an LSM without specifying semantics. Is there an expectation that inode_getsecctx return the value sent by inode_notifysecctx, or would you expect the "notify" secctx to be stored elsewhere? > Reasonable? I think that the theory is fine, but I forsee implementation complications if the details of what is expected of an LSM aren't clear. At this point I'm not objecting to the interface so much as hoping to be able to use it properly, even with my limited and deteriorating mental facilties. Thank you. Casey Schaufler casey@xxxxxxxxxxxxxxxx -- 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
