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?
--
Best regards,
Michal
http://eventhorizon.pl/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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.
--
Matthew Miller <mattdm@mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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.
--
Stephen Smalley
National Security Agency
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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/
+ /* 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;
+ }
+ }
+
/* Drop back to detecting it the long way. */
fp = fopen("/proc/filesystems", "r");
if (!fp)
diff --git a/libselinux/src/load_policy.c b/libselinux/src/load_policy.c
index 83d2143..4078f69 100644
--- a/libselinux/src/load_policy.c
+++ b/libselinux/src/load_policy.c
@@ -369,7 +369,17 @@ int selinux_init_load_policy(int *enforce)
* Check for the existence of SELinux via selinuxfs, and
* mount it if present for use in the calls below.
*/
- if (mount("selinuxfs", SELINUXMNT, "selinuxfs", 0, 0) < 0 && errno != EBUSY) {
+ char *mntpoint = NULL;
+ if (mount("selinuxfs", SELINUXMNT, "selinuxfs", 0, 0) == 0 || errno == EBUSY) {
+ mntpoint = SELINUXMNT;
+ } else {
+ /* check old mountpoint */
+ if (mount("selinuxfs", "/selinux", "selinuxfs", 0, 0) == 0 || errno == EBUSY) {
+ mntpoint = "/selinux";
+ }
+ }
+
+ if (! mntpoint ) {
if (errno == ENODEV) {
/*
* SELinux was disabled in the kernel, either
@@ -384,8 +394,8 @@ int selinux_init_load_policy(int *enforce)
}
/* selinuxfs mount point */
extern char *selinux_mnt;
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2011/4/29 seth vidal <skvidal@fedoraproject.org>:
> 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.
On Fri, 2011-04-29 at 17:26 +0200, Michał Piotrowski wrote:
> 2011/4/29 seth vidal <skvidal@fedoraproject.org>:
> > 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 29.04.11 00:37, Michał Piotrowski (mkkp4x4@gmail.com) 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
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 29.04.11 17:26, Michał Piotrowski (mkkp4x4@gmail.com) wrote:
>
> 2011/4/29 seth vidal <skvidal@fedoraproject.org>:
> > 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
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
