[systemd-devel] [PATCH] SMACK: Add configuration options. (v3)

[Schaufler, Casey]

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: Tuesday, October 30, 2012 4:12 PM
> To: Schaufler, Casey
> Cc: Kok, Auke-jan H; systemd-devel at lists.freedesktop.org
> Subject: Re: [PATCH] SMACK: Add configuration options. (v3)
> 
> On Tue, 30.10.12 23:04, Schaufler, Casey (casey.schaufler at intel.com)
> wrote:
> 
> > Yup. That was the convention at the time Smack was introduced.
> >
> > > That should
> > > really be fixed. We moved all the other file systems (selinux,
> > > cgroups,
> > > ...) below /sys,
> >
> > No one said boo about Smack at the time.
> 
> Sorry about that, but I guess we didn't notice it since SMACK is not
> available on Fedora...

Yes, Fedora remains devoted to SELinux. Fedora is very popular
and in many ways influences the direction that user space interfaces
are presented.

> > > Follow the SELinux scheme please and introduce /sys/fs/smack, and
> > > use that as default mount point.
> >
> > I have been advocating standardization of LSM interfaces for some
> > time. The apparmor folks put theirs at /sys/kernel/security/apparmor.
> > I would hardly say that /sys/fs/smack would be better than
> > /sys/kernel/security/smack.
> > I plan to move it when there's a consensus of where LSM filesystems
> > should go, or when there's a compelling reason to go someplace in
> > particular. I'm afraid that "SELinux does in this way" is not an
> > argument *by itself* that goes very far with the Smack project.
> 
> I think the rule was that if its an fs of its own it should be in
> /sys/fs, but if it is implemented based on securityfs then it should of
> course appear below /sys/kernel/security.
> 
> Given that SMACK and SELinux have their own file systems /sys/fs/smack
> and /sys/fs/selinux sounds like the right choice. And AppArmor uses
> securityfs, hence /sys/kernel/security/apparmor is their root of the
> tree.
> 
> I hope that makes some sense?

Some. If we wanted to have a convention that really works the
underlying implementation should not be a factor. I personally
don't care much where the smackfs filesystem gets mounted. We
can certainly adjust userspace code to accommodate the fact
that sometimes it's here and sometimes it's there. What I don't
want is for it to be one place on Fedora, another on Ubuntu, a
third on Tizen and all because each disto is holding to a
different convention.

Smack has "kernel based" as a design center. I don't believe
in hiding behind abstractions and APIs. Programs that utilize
Smack today often use the filesystem interfaces directly. So
it could be a bit of a bother to change the mount point. Not
too much, I suppose, but a bother nonetheless.


> 
> Lennart
> 
> --
> Lennart Poettering - Red Hat, Inc.