From: andronicus.spiros@gmail.com (Elia Pinto) Date: Sun, 16 Sep 2012 21:31:52 +0200 Subject: [refpolicy] [PATCH] Add Debian location for rtkit-daemon daemon In-Reply-To: <1347733143.2915.45.camel@d30.localdomain> References: <1347488050-19736-1-git-send-email-bigon@debian.org> <1347538790.2915.20.camel@d30.localdomain> <50520213.40902@redhat.com> <1347552374.2915.27.camel@d30.localdomain> <20120915133543.7a7857e0@fornost.bigon.be> <1347733143.2915.45.camel@d30.localdomain> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 : > > > On Sat, 2012-09-15 at 20:08 +0200, Sven Vermeulen wrote: >> >> On Sep 15, 2012 1:35 PM, "Laurent Bigonville" wrote >> > 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. > > > 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. > >> _______________________________________________ >> 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 > -- Inviato dal mio dispositivo mobile