On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers <[email protected]> wrote: > On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H > <[email protected]> wrote: >> On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena >> <[email protected]> wrote: > >>> For example, I can set a couple of smack-related xattrs in one go like >>> XATTR{security.SMACK64}="*", XATTR{security.SMACK64EXEC}="*". >>> Doesn't make sense from smack point of view (only smack64 is really >>> meaningful >>> on device nodes), but proves that functionality works. >> >> right, but we could be setting other non-SMACK xattrs now all in one >> go - for example, SELINUX ones ("security.selinux"). > > Yeah, *looks* powerful, but also scary. :) > > And selinux is not managed by visible strings exposed to tools, it's > all hidden in a library, and the database returns the stuff to apply. > There should never be the need to set any string from selinux with a > tool carrying static strings. > >> This looks OK to me, can you take another look at it? > > I still can't wrap my head around the issue that we can use udev rules > now to *add* things which will never get removed again. If we add a > rule that set one of these attributes, and remove the rule again, the > applied xattr will never be cleared. > > It all sounds not right to me, and I don't think we should go ahead > with anything like this before we have sorted out the responsibilities > and ownership of data we attach to device nodes. We do not do that for > anything else, things just don't pile up, they are reset, cleared when > the config goes away and an event is triggered. > > We probably need some concept of ownership, based on xattr names or > namespaces, soemthing that makes it clear who's responsible to > reset/clear the attributes when the config changes. > > Not sure, maybe we can just reset all xattrs with an "add" event, and > declare "add" as a form of reset to a prisitine state. > > The other issue is, that as nice as generic support for xattrs sounds, > it might in the end not be what we should offer to "random" users. > > I really can't decide at this moment, I have to think it through.
well, for Tizen at least, we need this functionality. Too many nodes appear in /dev/ that should only be accessible by certain services alone, and this is exactly what SMACK adds. A good example is that SMACK allows us to grant only camera (/dev/video/*) privileges to approved camera applications, instead of having every application for a user in a session have full access to the camera. We get the best of both access control methods. I realize that unsetting/removal is a concern, but I don't think it should preclude merging code that is better at setting/adding :^) The only alternative I see is to create another udev event listener and have that process set smack labels. That would just duplicate a lot of udev code... And it still doesn't solve the removal of rules - that would be something only a e.g. %post script could consistently do. Auke _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
