--- Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > > I am much more concerned with the interfaces used to pass the > > information into the kernel. I would expect that to be LSM > > independent, not a call into libselinux that resolves into a > > selinuxfs operation, or it's netlink equivilant. It would be > > unfortunate if the userland/kernel interface became an obstacle > > to cachefiles being adopted. > > That wasn't the issue. The interface to the cachefiles module would > just consist of cachefilesd writing a string label to some pseudo file > tell cachefiles what label to apply as the acting label for operations > performed by cachefiles. Which isn't SELinux-specific at all. Calm down. Just checking. > David was asking though how cachefilesd (the userspace agent) would > obtain such a label to use. And that may very well be LSM-specific, and > as there is no LSM userspace API, it makes sense for him to invoke a > libselinux function at present. If a liblsm is later created and > provides a common front-end API (internally dlopen'ing the right shared > library based on some configuration, whether libselinux or libsmack or > whatever), then cachefilesd can instead call the liblsm interface, but > that doesn't exist today. I am certainly not in favor of adding such complexity. I suggest that cachefilesd get the context it wants using whatever scheme works. I think there should be a cachefiles specific (LSM independent) scheme for getting it into the kernel, and a LSM hooks for setting it, if that's what he really wants to do. Casey Schaufler casey@xxxxxxxxxxxxxxxx -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
