2012/1/11 夜神 岩男 <supergiantpotato at yahoo.co.jp>: > >> Yes, the breakage came from having someone who didn't understand the >> needs define that policy. > > I think you are misunderstanding how SELinux policies are formed and how > they work. Its a *lot* less complicated and mysterious than you're > making it sound. For most applications its really, really easy to do this. You still haven't quantified this yet so I can understand what you consider 'really, really easy'. How many Fedora bugs have there been specifically related to this? >> So if an application only needs to do something once at some future >> time, what happens? If you write an application that will need to do >> something at some rare future time, what is the standard way to tell >> distribution packaging systems and system administrators to permit it? > > I'm trying to think of a single example (that isn't a worm) that fits > this description. > > Can you think of any examples? (again, worms don't count... actually, > that is sort of the point here...) For an obvious case, consider an application that needs to send mail but only does it when certain errors happen. Or an application that is configured to fail over using different ports/addresses/sockets that won't be used until the primary fails and may never be seen in an attempt to guess what is supposed to be happening. Or distributed applications that negotiate connections. What about something like the remote monitoring instances that OpenNMS can instantiate with java's RMI capabilities? > No, there are tools that do almost all the work for you. Its much easier > than learning how to write a spec file in the first place. At this point > it sounds like you're just arguing against something you're refusing to > find out more about No, I'm arguing that I don't know how to exchange this information in a useful way. And that I don't believe reverse-engineering is the best approach to it. Assuming I would write a new application, how would I confer the knowledge about the needed policy to the places where it needs to be enacted. You can even take distributions out of the context of this question. If a local development group is building/changing applications, what is the expected way for them to inform the system administrators or the operators that will be installing it about the policy needs? -- which is the standard human policy towards > SELinux, so you're in good company (it used to be the standard human > policy toward ipchains back in the day, too). No, it is the standard human policy when policy makers try to impose policy in ways that don't make sense. >You can just turn it off if it bothers you so much. That kind of misses the point. You could run everything as root if you wanted and make all your files mode 777. The reason people don't is that application programs have ways to use lower privileges and ways to represent what is needed. For other restrictions to be widely usable you need standard ways to represent what is required and exchange that information. -- Les Mikesell lesmikesell at gmail.com