systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?

[Michał Piotrowski]

Hi,

I think it's a very good decision - I never understood why selinux dir
is directly under /.

By the way, maybe it would be good to think about the meaning of /srv
existance? For seven years FHS requires that this directory exists
http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
but "The methodology used to name subdirectories of /srv is
unspecified as there is currently no consensus on how this should be
done" - so even the authors of the standard did not have anything to
say about how this directory should be used. Is there a rational
reason for the existence of this directory besides FHS conformance?

[Matthew Miller]

On Fri, Apr 29, 2011 at 12:37:26AM +0200, Michał Piotrowski wrote:
> By the way, maybe it would be good to think about the meaning of /srv
> existance? For seven years FHS requires that this directory exists
> http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> but "The methodology used to name subdirectories of /srv is
> unspecified as there is currently no consensus on how this should be
> done" - so even the authors of the standard did not have anything to
> say about how this directory should be used. Is there a rational
> reason for the existence of this directory besides FHS conformance?

Yes. It's where to put non-transient service data that does not belong to a
user, and does not belong to a package.

[Seth Vidal]

On Thu, 2011-04-28 at 23:32 -0400, Matthew Miller wrote:
> On Fri, Apr 29, 2011 at 12:37:26AM +0200, Michał Piotrowski wrote:
> > By the way, maybe it would be good to think about the meaning of /srv
> > existance? For seven years FHS requires that this directory exists
> > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> > but "The methodology used to name subdirectories of /srv is
> > unspecified as there is currently no consensus on how this should be
> > done" - so even the authors of the standard did not have anything to
> > say about how this directory should be used. Is there a rational
> > reason for the existence of this directory besides FHS conformance?
>
> Yes. It's where to put non-transient service data that does not belong to a
> user, and does not belong to a package.

+1 - I think /srv is a good dir to have in place to encourage good
practices for storing that kind of data.

-sv

[Michał Piotrowski]

2011/4/29 seth vidal :
> On Thu, 2011-04-28 at 23:32 -0400, Matthew Miller wrote:
> > On Fri, Apr 29, 2011 at 12:37:26AM +0200, Michał Piotrowski wrote:
> > > By the way, maybe it would be good to think about the meaning of /srv
> > > existance? For seven years FHS requires that this directory exists
> > > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> > > but "The methodology used to name subdirectories of /srv is
> > > unspecified as there is currently no consensus on how this should be
> > > done" - so even the authors of the standard did not have anything to
> > > say about how this directory should be used. Is there a rational
> > > reason for the existence of this directory besides FHS conformance?
> >
> > Yes. It's where to put non-transient service data that does not belong to a
> > user, and does not belong to a package.
>
> +1 - I think /srv is a good dir to have in place to encourage good
> practices for storing that kind of data.

I think it is very unlikely that the services will start to use /srv/
instead of /var/something because of the backward compatibility. I
create my own dir for data and it seemed to me that most people are
doing the same. Thats why I wondered if there is any use for this dir.
> -sv
>
> --
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel

[Seth Vidal]

On Fri, 2011-04-29 at 17:26 +0200, Michał Piotrowski wrote:
> 2011/4/29 seth vidal :
> > On Thu, 2011-04-28 at 23:32 -0400, Matthew Miller wrote:
> > > On Fri, Apr 29, 2011 at 12:37:26AM +0200, Michał Piotrowski wrote:
> > > > By the way, maybe it would be good to think about the meaning of /srv
> > > > existance? For seven years FHS requires that this directory exists
> > > > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> > > > but "The methodology used to name subdirectories of /srv is
> > > > unspecified as there is currently no consensus on how this should be
> > > > done" - so even the authors of the standard did not have anything to
> > > > say about how this directory should be used. Is there a rational
> > > > reason for the existence of this directory besides FHS conformance?
> > >
> > > Yes. It's where to put non-transient service data that does not belong to a
> > > user, and does not belong to a package.
> >
> > +1 - I think /srv is a good dir to have in place to encourage good
> > practices for storing that kind of data.
>
> I think it is very unlikely that the services will start to use /srv/
> instead of /var/something because of the backward compatibility. I
> create my own dir for data and it seemed to me that most people are
> doing the same. Thats why I wondered if there is any use for this dir.

services should not be using /srv by default - I said it is a good habit
for admins to get into so places where they store data are commonly
available in normal locations
-sv

[Lennart Poettering]

On Fri, 29.04.11 17:26, Michał Piotrowski ([e-mail]) wrote:
> 2011/4/29 seth vidal :
> > On Thu, 2011-04-28 at 23:32 -0400, Matthew Miller wrote:
> > > On Fri, Apr 29, 2011 at 12:37:26AM +0200, Michał Piotrowski wrote:
> > > > By the way, maybe it would be good to think about the meaning of /srv
> > > > existance? For seven years FHS requires that this directory exists
> > > > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> > > > but "The methodology used to name subdirectories of /srv is
> > > > unspecified as there is currently no consensus on how this should be
> > > > done" - so even the authors of the standard did not have anything to
> > > > say about how this directory should be used. Is there a rational
> > > > reason for the existence of this directory besides FHS conformance?
> > >
> > > Yes. It's where to put non-transient service data that does not belong to a
> > > user, and does not belong to a package.
> >
> > +1 - I think /srv is a good dir to have in place to encourage good
> > practices for storing that kind of data.
>
> I think it is very unlikely that the services will start to use /srv/
> instead of /var/something because of the backward compatibility. I
> create my own dir for data and it seemed to me that most people are
> doing the same. Thats why I wondered if there is any use for this dir.

/srv is not package manager territory really. It's admin territory. He
should create dirs underneath it, and nobody else.

Lennart

[nodata]

On 29/04/11 00:37, Michał Piotrowski wrote:
> Hi,
>
> I think it's a very good decision - I never understood why selinux dir
> is directly under /.
>
> By the way, maybe it would be good to think about the meaning of /srv
> existance? For seven years FHS requires that this directory exists
> http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> but "The methodology used to name subdirectories of /srv is
> unspecified as there is currently no consensus on how this should be
> done" - so even the authors of the standard did not have anything to
> say about how this directory should be used. Is there a rational
> reason for the existence of this directory besides FHS conformance?

These are two separate issues. /srv tends to prevent people creating top 
level mounts, so I would definitely keep it.

[Stephen Smalley]

On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote:
> Hi,
>
> I think it's a very good decision - I never understood why selinux dir
> is directly under /.

I guess I missed some discussion of this.  You'd need to update
libselinux at least, definition of SELINUXMNT in
libselinux/src/policy.h, used by selinux_init_load_policy() to mount
selinuxfs for initial policy load.  And it may break rc scripts and
other scripts/programs that have become accustomed to /selinux.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/29/2011 11:07 AM, Stephen Smalley wrote:
> On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote:
> > Hi,
> >
> > I think it's a very good decision - I never understood why selinux dir
> > is directly under /.
>
> I guess I missed some discussion of this.  You'd need to update
> libselinux at least, definition of SELINUXMNT in
> libselinux/src/policy.h, used by selinux_init_load_policy() to mount
> selinuxfs for initial policy load.  And it may break rc scripts and
> other scripts/programs that have become accustomed to /selinux.

Here is the patch I am thinking about.

I think mock might need to be updated, maybe livecd tools.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2615cACgkQrlYvE4MpobPYlQCfeB3H0/eTVITUbOkv66/P+0DB
> 7pAAn3nYJZSDLyJnDv7+VXwTlZQ3TW9R
> =2hkb
> -----END PGP SIGNATURE-----

[Lennart Poettering]

On Fri, 29.04.11 11:21, Daniel J Walsh ([e-mail]) wrote:
> > I guess I missed some discussion of this.  You'd need to update
> > libselinux at least, definition of SELINUXMNT in
> > libselinux/src/policy.h, used by selinux_init_load_policy() to mount
> > selinuxfs for initial policy load.  And it may break rc scripts and
> > other scripts/programs that have become accustomed to /selinux.
>
> Here is the patch I am thinking about.
>
> I think mock might need to be updated, maybe livecd tools.
> /* We check to see if the original mount point for selinux file
> * system has a selinuxfs. */
> do {
> rc = statfs("/selinux", &sfbuf);
> } while (rc < 0 && errno == EINTR);
> if (rc == 0) {
> if ((uint32_t)sfbuf.f_type == (uint32_t)SELINUX_MAGIC) {
> 	selinux_mnt = strdup("/selinux");
> 	return;
> }

I like the patch.

One little feature request where we already are on this:

Given that there is a statfs() in here anyway, could we also maybe
extend this a tiny bit, and add a statvfs() call as well, and if
ST_RDONLY is set in .f_flag consider selinux to be off? That would be
very handy in containers/chroots and stuff like that, where you might
want to make the container assume selinux is off even though the host
has it enabled. If the container/chroot manager simply bind mounts
/selinux into the namespace read-only this would then be an effective
way to make selinux appear off to the container code.

I think using whether /selinux is read-only as a flag for selinux off is
a pretty natural nice way.

mock currently tries do work-around this by placing a fake
/proc/filesystems file in the namespace, and I think that's quite
ugly. Using read-only /selinux as flag appears much nicer to me, since
it in itself already disables a number of selinux operations.

Lennart

[Lennart Poettering]

On Fri, 29.04.11 11:07, Stephen Smalley ([e-mail]) wrote:
> On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote:
> > Hi,
> >
> > I think it's a very good decision - I never understood why selinux dir
> > is directly under /.
>
> I guess I missed some discussion of this.  You'd need to update
> libselinux at least, definition of SELINUXMNT in
> libselinux/src/policy.h, used by selinux_init_load_policy() to mount
> selinuxfs for initial policy load.  And it may break rc scripts and
> other scripts/programs that have become accustomed to /selinux.

Yupp, systemd would also need a fix for this. But I'd be more than happy
to make this change.

Lennart

[Lennart Poettering]

On Fri, 29.04.11 00:37, Michał Piotrowski ([e-mail]) wrote:
> Hi,
>
> I think it's a very good decision - I never understood why selinux dir
> is directly under /.

Yes, I think this would be a good thing to have in F16.

Note however that this needs a tiny kernel patch to work, to create the
mount point under /sys/fs/selinux. This is a trivial patch and has been
done for /sys/fs/cgroup before, so I assume this would be easy to get
in and just needs a champion to push this forward.
> By the way, maybe it would be good to think about the meaning of /srv
> existance? For seven years FHS requires that this directory exists
> http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> but "The methodology used to name subdirectories of /srv is
> unspecified as there is currently no consensus on how this should be
> done" - so even the authors of the standard did not have anything to
> say about how this directory should be used. Is there a rational
> reason for the existence of this directory besides FHS conformance?

I think /srv actually makes a lot of sense. Probably not so much on the
desktop, but the boundaries are blurry, and I see no reason to set
things up differently in this respect between servers and desktops. I
see little benefit in removing this directory.

Lennart

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/29/2011 06:56 PM, Lennart Poettering wrote:
> On Fri, 29.04.11 00:37, Michał Piotrowski ([e-mail]) wrote:
> > Hi,
> >
> > I think it's a very good decision - I never understood why selinux dir
> > is directly under /.
>
> Yes, I think this would be a good thing to have in F16.
>
> Note however that this needs a tiny kernel patch to work, to create the
> mount point under /sys/fs/selinux. This is a trivial patch and has been
> done for /sys/fs/cgroup before, so I assume this would be easy to get
> in and just needs a champion to push this forward.
> > By the way, maybe it would be good to think about the meaning of /srv
> > existance? For seven years FHS requires that this directory exists
> > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> > but "The methodology used to name subdirectories of /srv is
> > unspecified as there is currently no consensus on how this should be
> > done" - so even the authors of the standard did not have anything to
> > say about how this directory should be used. Is there a rational
> > reason for the existence of this directory besides FHS conformance?
>
> I think /srv actually makes a lot of sense. Probably not so much on the
> desktop, but the boundaries are blurry, and I see no reason to set
> things up differently in this respect between servers and desktops. I
> see little benefit in removing this directory.
>
> Lennart

I think moving /selinux is  a bit more complicated then just a simple
kernel change.  We have libselinux changes, Lots of tools have learned
over the years the path of /selinux and lots of users know about it.

I am willing to work towards the goal of moving /selinux, but I might
end up with a symbolic link if we can not fix all of the problems.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk27RKUACgkQrlYvE4MpobOCoACgvLrAnXtzvxV7ztHP4aiGr8Df
> VZ4AnAnqTzUofp62+IHkc9WmTvh74sRE
> =NLi7
> -----END PGP SIGNATURE-----

[systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?

[Michał Piotrowski]

2011/4/30 Daniel J Walsh :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/29/2011 06:56 PM, Lennart Poettering wrote:
> > On Fri, 29.04.11 00:37, Michał Piotrowski ([e-mail]) wrote:
> > > Hi,
> > >
> > > I think it's a very good decision - I never understood why selinux dir
> > > is directly under /.
> >
> > Yes, I think this would be a good thing to have in F16.
> >
> > Note however that this needs a tiny kernel patch to work, to create the
> > mount point under /sys/fs/selinux. This is a trivial patch and has been
> > done for /sys/fs/cgroup before, so I assume this would be easy to get
> > in and just needs a champion to push this forward.
> > > By the way, maybe it would be good to think about the meaning of /srv
> > > existance? For seven years FHS requires that this directory exists
> > > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A
> > > but "The methodology used to name subdirectories of /srv is
> > > unspecified as there is currently no consensus on how this should be
> > > done" - so even the authors of the standard did not have anything to
> > > say about how this directory should be used. Is there a rational
> > > reason for the existence of this directory besides FHS conformance?
> >
> > I think /srv actually makes a lot of sense. Probably not so much on the
> > desktop, but the boundaries are blurry, and I see no reason to set
> > things up differently in this respect between servers and desktops. I
> > see little benefit in removing this directory.
> >
> > Lennart
>
> I think moving /selinux is  a bit more complicated then just a simple
> kernel change.  We have libselinux changes, Lots of tools have learned
> over the years the path of /selinux and lots of users know about it.
>
> I am willing to work towards the goal of moving /selinux, but I might
> end up with a symbolic link if we can not fix all of the problems.

What was the original intention of creating selinux directory directly
under / ? Was this file system created at a 2.4 times when sysfs
didn't existed yet?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk27RKUACgkQrlYvE4MpobOCoACgvLrAnXtzvxV7ztHP4aiGr8Df
> VZ4AnAnqTzUofp62+IHkc9WmTvh74sRE
> =NLi7
> -----END PGP SIGNATURE-----
> _______________________________________________
> systemd-devel mailing list
> [e-mail]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel