Add Debian location for rtkit-daemon daemon
PATCH 1/1 Add Debian location for rtkit-daemon daemon
From: Laurent Bigonville <[email protected]>
--- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
rtkit.fc +4 -0
@@ -1 +1,5 @@ /usr/libexec/rtkit-daemon -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) + +ifdef(`distro_debian',` +/usr/lib/rtkit/rtkit-daemon -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +')
Signature · 1 line
1.7.10.4
PATCH 1/1 Add Debian location for rtkit-daemon daemon
Quoted 11 lines · Laurent Bigonville
From: Laurent Bigonville <[email protected]>
--- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)rtkit.fc +0
-0
rtkit.fc line 5
Quoted 5 lines
rtkit.fc +4
-0@@ -1 +1,5 @@ /usr/libexec/rtkit-daemon -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) + +ifdef(`distro_debian',` +/usr/lib/rtkit/rtkit-daemon -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +')
This was merged. Thanks
PATCH 1/1 Add Debian location for rtkit-daemon daemon
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 15 lines · Dominick Grift
Quoted 9 lines · Laurent Bigonville
From: Laurent Bigonville <[email protected]>
--- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
rtkit.fc index 52c441e..fd82305 100644 --- renamed from rtkit.fc +0
-0a/rtkit.fc +++ b/rtkit.fc @@ -1 +1,5 @@
/usr/libexec/rtkit-daemon--gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)+
+ifdef(distro_debian',+/usr/lib/rtkit/rtkit-daemon --gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)+')This was merged. Thanks
Quoted 3 lines
_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
I have never been a big fan of the ifdef(DISTRO) stuff in the fc files. Why is it necessary hear? Only reason for this would be if another distro had a file here named /usr/lib/rtkit/rtkit-daemon that they wanted to label differently.
Lets not flood the fc files with these macros. I could definitely see Fedora
moving to this location. Driven by systemd.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBSAhMACgkQrlYvE4MpobPSZwCcCR2+DEOBscaO5+tAW8MVeh/1 v54AoLQLibo8L9y6id4oXH1ukQJJ3SLC
=GfgV
-----END PGP SIGNATURE-----
PATCH 1/1 Add Debian location for rtkit-daemon daemon
Quoted 16 lines · Daniel J Walsh
Quoted 15 lines · Dominick Grift
Quoted 9 lines · Laurent Bigonville
From: Laurent Bigonville <[email protected]>
--- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
rtkit.fc index 52c441e..fd82305 100644 --- renamed from rtkit.fc +0
-0a/rtkit.fc +++ b/rtkit.fc @@ -1 +1,5 @@
/usr/libexec/rtkit-daemon--gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)+
+ifdef(distro_debian',+/usr/lib/rtkit/rtkit-daemon --gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)+')This was merged. Thanks
Quoted 8 lines
Quoted 3 lines
_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
I have never been a big fan of the ifdef(DISTRO) stuff in the fc files. Why is it necessary hear? Only reason for this would be if another distro had a file here named
/usr/lib/rtkit/rtkit-daemonthat they wanted to label differently.
Lets not flood the fc files with these macros. I could definitely see Fedora
moving to this location. Driven by systemd.
I agree, but until we get consensus cross the board regarding this issue i don't see any reason to reject these patches.
removing the ifdef wrappers is trivial so as soon as we can all agree ill remove them.
So i would like to hear opinions of at least pebenito. bigon and swift about this as well (which i cc'd)
A message that is not in the archive (sent off-list or not yet received): CAPzO=NxQt0cecrjV3r-NYFhPoJrk-wWj37GeC2i8SXRc9vf0Xg@mail.gmail.com
PATCH 1/1 Add Debian location for rtkit-daemon daemon
Quoted 1 line · Dominick Grift
Quoted 1 line
it necessary hear? Only reason for this would be if another distro had
a file
Quoted 1 line
Quoted 1 line
here named
/usr/lib/rtkit/rtkit-daemonthat they wanted to label
differently.
Quoted 1 line
Quoted 1 line
Lets not flood the fc files with these macros. I could definitely see
Fedora
Quoted 11 lines
Quoted 1 line
moving to this location. Driven by systemd.
I agree, but until we get consensus cross the board regarding this issue i don't see any reason to reject these patches.
removing the ifdef wrappers is trivial so as soon as we can all agree ill remove them.
So i would like to hear opinions of at least pebenito. bigon and swift about this as well (which i cc'd)
I'm ok with it. I assume the impact is mainly that we will see a lot more context definitions, but not really any problems - including performance. -------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20120914/47a13469/attachment.html
PATCH 1/1 Add Debian location for rtkit-daemon daemon
In reply to Dominick GriftLe Thu, 13 Sep 2012 18:06:14 +0200, Dominick Grift <[email protected]> a ?crit :
Quoted 8 lines
I agree, but until we get consensus cross the board regarding this issue i don't see any reason to reject these patches.
removing the ifdef wrappers is trivial so as soon as we can all agree ill remove them.
So i would like to hear opinions of at least pebenito. bigon and swift about this as well (which i cc'd)
Shouldn't we add some comments to keep track of distro specific paths? Otherwise, if at some point, we want to make some cleanup it might become difficult to track if a path is still required.
Otherwise, I've no strong opinion on this subject.
Cheers
Laurent Bigonville
PATCH 1/1 Add Debian location for rtkit-daemon daemon
On Sep 15, 2012 1:35 PM, "Laurent Bigonville" <[email protected]> wrote
Quoted 3 lines
Shouldn't we add some comments to keep track of distro specific paths? Otherwise, if at some point, we want to make some cleanup it might become difficult to track if a path is still required.
You even have this 'problem' for non-distro specific locations, such as locations that change with newer program releases. OK, we make it a bit worse here, but I think this is minor compared to the obsolete locations due to older software releases.
I think that if we look at locations module by module, we should be able to clean up things. However, lots of locations are mentioned in corecommands
and libraries. Those might be more difficult to relate. Which was why I suggested to perhaps allow bin/lib in module specific fc files earlier. -------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20120915/c3179fef/attachment.html
PATCH 1/1 Add Debian location for rtkit-daemon daemon
Quoted 12 lines · Sven Vermeulen
On Sep 15, 2012 1:35 PM, "Laurent Bigonville" <[email protected]> wrote
Quoted 1 line
Shouldn't we add some comments to keep track of distro specific
paths?
Quoted 2 lines
Otherwise, if at some point, we want to make some cleanup it might become difficult to track if a path is still required.
You even have this 'problem' for non-distro specific locations, such as locations that change with newer program releases. OK, we make it a bit worse here, but I think this is minor compared to the obsolete locations due to older software releases.
Quoted 5 lines
I think that if we look at locations module by module, we should be able to clean up things. However, lots of locations are mentioned in corecommands and libraries. Those might be more difficult to relate. Which was why I suggested to perhaps allow bin/lib in module specific fc files earlier.
I just encountered something related today when i was porting stuff from fedora to contrib.
The afs module was basically not used in fedora because fedora has the entry files in a location that was not in the file context file.
Anyways i just added those and left the old stuff because we need to consider backwards compatibility.
So i am saying, for now not to worry about obsolete file contexts, you never know who still have files in old locations.
Thats also another thing that sucks, the chances we find such issues that i described above are slim because by default anything that initrc runs get run in a unconfined domain if it has a generic executable file type.
So if you dont know where to look, its hard to determine whether policy is actually enforced or whether the app runs unprotected.
The only way to figure that out is to disable the unconfined module.
or to review each policy module carefully as i am doing.
Quoted 4 lines
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
PATCH 1/1 Add Debian location for rtkit-daemon daemon
If you like to hear a luser, more or less, opinion mostly the problem that today the refpolicy have is because exists other project that forked it, right or wrong it is not important. And apparently none care. And none care where someone have to send patches, improvment , new policy. Is it a good thing ? Perhaps i have missed something ? Dunno
2012/9/15, Dominick Grift <[email protected]>:
Quoted 57 lines · Sven Vermeulen
Quoted 12 lines
On Sep 15, 2012 1:35 PM, "Laurent Bigonville" <[email protected]> wrote
Quoted 1 line
Shouldn't we add some comments to keep track of distro specific
paths?
Quoted 2 lines
Otherwise, if at some point, we want to make some cleanup it might become difficult to track if a path is still required.
You even have this 'problem' for non-distro specific locations, such as locations that change with newer program releases. OK, we make it a bit worse here, but I think this is minor compared to the obsolete locations due to older software releases.
Quoted 5 lines
I think that if we look at locations module by module, we should be able to clean up things. However, lots of locations are mentioned in corecommands and libraries. Those might be more difficult to relate. Which was why I suggested to perhaps allow bin/lib in module specific fc files earlier.
I just encountered something related today when i was porting stuff from fedora to contrib.
The afs module was basically not used in fedora because fedora has the entry files in a location that was not in the file context file.
Anyways i just added those and left the old stuff because we need to consider backwards compatibility.
So i am saying, for now not to worry about obsolete file contexts, you never know who still have files in old locations.
Thats also another thing that sucks, the chances we find such issues that i described above are slim because by default anything that initrc runs get run in a unconfined domain if it has a generic executable file type.
So if you dont know where to look, its hard to determine whether policy is actually enforced or whether the app runs unprotected.
The only way to figure that out is to disable the unconfined module.
or to review each policy module carefully as i am doing.
Quoted 4 lines
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
Signature · 1 line
Inviato dal mio dispositivo mobile
PATCH 1/1 Add Debian location for rtkit-daemon daemon
Quoted 6 lines · Elia Pinto
If you like to hear a luser, more or less, opinion mostly the problem that today the refpolicy have is because exists other project that forked it, right or wrong it is not important. And apparently none care. And none care where someone have to send patches, improvment , new policy. Is it a good thing ? Perhaps i have missed something ? Dunno
I do not believe that it is true that no one cares but distributions do sometimes have priorities that do not always align with upstreams' priorities. It is a tough world out there for businesses that need to send pay checks to employees.
I think that people understand that working with upstream is probably the sustainable solution in the long term. It is just easier said than done when one is facing deadlines et cetera.
Also it is a matter of resources for those community projects that do not have a commercial incentive i suspect. Many distributions do not enable selinux by default and do not have many policy authors and contributors.
Currently we have, in my view, a good impulse. We have SwifT on behalf of Gentoo contributing and we have bigon contributing on behalf of debian.
I currently do some porting for and contributing on behalf of Fedora and hopefully mgrepl will also help out, and help solve remaining issues.
Reference policy is called this way for a reason and so i guess it is reasonable to expect some changes between policies that distributions ship and refpolicy. However there does not have to a big difference since essentially the policy that a distribution ships is also a reference policy and both are pretty much general purpose policies.
Anyways, this is off topic in my opinion. This topic is about not using if(n)?def(`') in file context files and i think that it should not be a big problem to have some possibly redundant file context specs for the sake of guaranteeing backwards compatibility.
PATCH 1/1 Add Debian location for rtkit-daemon daemon
In reply to Dominick GriftQuoted 26 lines · Dominick Grift
Quoted 17 lines · Daniel J Walsh
Quoted 7 lines · Dominick Grift
Quoted 4 lines · Laurent Bigonville
From: Laurent Bigonville <[email protected]>
--- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
Quoted 9 lines
Quoted 5 lines
rtkit.fc index 52c441e..fd82305 100644 --- renamed from rtkit.fc +0
-0a/rtkit.fc +++ b/rtkit.fc @@ -1 +1,5 @@
/usr/libexec/rtkit-daemon--gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)+
+ifdef(distro_debian',+/usr/lib/rtkit/rtkit-daemon --gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)+')This was merged. Thanks
Quoted 5 lines
I have never been a big fan of the ifdef(DISTRO) stuff in the fc files. Why is it necessary hear? Only reason for this would be if another distro had a file here named
/usr/lib/rtkit/rtkit-daemonthat they wanted to label differently.
Lets not flood the fc files with these macros. I could definitely see Fedora
moving to this location. Driven by systemd.
Quoted 8 lines
I agree, but until we get consensus cross the board regarding this issue i don't see any reason to reject these patches.
removing the ifdef wrappers is trivial so as soon as we can all agree ill remove them.
So i would like to hear opinions of at least pebenito. bigon and swift about this as well (which i cc'd)
We can always remove the ifdef if Fedora uses that path. But in this case, the fc seems odd to me; why would you put a service's executable in /usr/lib (even as a subdir)?
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 1/1 Add Debian location for rtkit-daemon daemon
Le Mon, 17 Sep 2012 11:17:17 -0400,
"Christopher J. PeBenito" <[email protected]> a ?crit :
Quoted 3 lines
We can always remove the ifdef if Fedora uses that path. But in this case, the fc seems odd to me; why would you put a service's executable in
/usr/lib(even as a subdir)?
Debian is not using libexec and puts these files in /usr/lib/*/ instead
PATCH 1/1 Add Debian location for rtkit-daemon daemon
Quoted 8 lines · Laurent Bigonville
Le Mon, 17 Sep 2012 11:17:17 -0400,
"Christopher J. PeBenito" <[email protected]> a ?crit :Quoted 3 lines
We can always remove the ifdef if Fedora uses that path. But in this case, the fc seems odd to me; why would you put a service's executable in
/usr/lib(even as a subdir)?Debian is not using libexec and puts these files in
/usr/lib/*/instead
To clarify, I wasn't saying the patch should be rejected, but rather that because it seems like a very nontraditional place, I think it would warrant using the ifdef.
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 1/1 Add Debian location for rtkit-daemon daemon
In reply to Christopher J. PeBenito-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 34 lines · Christopher J. PeBenito
Quoted 33 lines · Dominick Grift
Quoted 17 lines · Daniel J Walsh
Quoted 7 lines · Dominick Grift
Quoted 4 lines · Laurent Bigonville
From: Laurent Bigonville <[email protected]>
--- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
Quoted 9 lines
Quoted 5 lines
rtkit.fc index 52c441e..fd82305 100644 --- renamed from rtkit.fc +0
-0a/rtkit.fc +++ b/rtkit.fc @@ -1 +1,5 @@
/usr/libexec/rtkit-daemon--gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)+
+ifdef(distro_debian',+/usr/lib/rtkit/rtkit-daemon --gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)+')This was merged. Thanks
Quoted 6 lines
I have never been a big fan of the ifdef(DISTRO) stuff in the fc files. Why is it necessary hear? Only reason for this would be if another distro had a file here named
/usr/lib/rtkit/rtkit-daemonthat they wanted to label differently. Lets not flood the fc files with these macros. I could definitely see Fedora moving to this location. Driven by systemd.I agree, but until we get consensus cross the board regarding this issue i don't see any reason to reject these patches.
removing the ifdef wrappers is trivial so as soon as we can all agree ill remove them.
Quoted 7 lines
Quoted 2 lines
So i would like to hear opinions of at least pebenito. bigon and swift about this as well (which i cc'd)
We can always remove the ifdef if Fedora uses that path. But in this case, the fc seems odd to me; why would you put a service's executable in
/usr/lib(even as a subdir)?
Systemd is pushing the idea that you put apps that are to be run as a service or by a library into /usr/lib/PACKAGENAME (This apps should never be run using multilib). As opposed to /usr/libexec.
These are the directories I have in Fedora 18
/usr/lib/gconv/usr/lib/sse2/usr/lib/jvm/usr/lib/cups/usr/lib/udev/usr/lib/debug/usr/lib/alsa/usr/lib/krb5/usr/lib/dracut/usr/lib/kbd/usr/lib/jvm-private/usr/lib/jvm-exports/usr/lib/rtkaio/usr/lib/bonobo/usr/lib/games/usr/lib/binfmt.d/usr/lib/grub/usr/lib/security/usr/lib/crda/usr/lib/gcc/usr/lib/udisks2/usr/lib/modprobe.d/usr/lib/systemd/usr/lib/python2.7/usr/lib/mozilla/usr/lib/locale/usr/lib/python3.3/usr/lib/audit/usr/lib/gems/usr/lib/jvm-commmon/usr/lib/modules/usr/lib/firmware/usr/lib/tmpfiles.d/usr/lib/xen/usr/lib/modules-load.d/usr/lib/i686/usr/lib/polkit-1/usr/lib/yum-plugins/usr/lib/sysctl.d/usr/lib/man2html/usr/lib/rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBXQNwACgkQrlYvE4MpobNk2gCeLJAykDVtnEfo7NMYut308v/z LQgAn2+Tibfah9G9+LsbOhSB9W4P0RAf
=uwrK
-----END PGP SIGNATURE-----
PATCH 1/1 Add Debian location for rtkit-daemon daemon
Quoted 1 line · Daniel J Walsh
Systemd is pushing the idea that you put apps that are to be run as a
service
Quoted 1 line
or by a library into
/usr/lib/PACKAGENAME(This apps should never be run
using
Quoted 1 line
multilib). As opposed to
/usr/libexec.
Wouldn't it be a good idea to use a different label for these? They aren't
meant to be executed by individuals xirectly are they? So bin_t might not
be as good. What about a service_exec_t or so?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20120917/a8cdf2d6/attachment-0001.html
PATCH 1/1 Add Debian location for rtkit-daemon daemon
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 7 lines · Sven Vermeulen
Quoted 3 lines · On Sep 17, 2012 5:25 PM, "Daniel J Walsh" <[email protected]…
Systemd is pushing the idea that you put apps that are to be run as a service or by a library into
/usr/lib/PACKAGENAME(This apps should never be run using multilib). As opposed to/usr/libexec.
Quoted 9 lines
Wouldn't it be a good idea to use a different label for these? They aren't meant to be executed by individuals xirectly are they? So
bin_tmight not be as good. What about aservice_exec_tor so?_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
Most of these would not be labeled bin_t, they would be labeled systemd_exec_t, init_exec_t, udev_exec_t ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBXQmQACgkQrlYvE4MpobMWogCeKCh6zMIAq9nIPHGmaG2zwIUR NWgAoOTJzR4FRiPoVxHnlBeWDFX7FNIm
=oPMB
-----END PGP SIGNATURE-----