> HOWEVER: Looking more closely at my latest CentOS box makes me think > that something's wrong with your installation, since I can run > "systemctl restart postfix" without any problems. Note: > > # ls -lZ /var/spool/postfix/private/defer > srw-rw-rw-. postfix postfix system_u:object_r:postfix_private_t:s0 > /var/spool/postfix/private/defer > > You may not have a policy bug, but a deployment error of some sort which > caused that socket to be mislabeled.
I checked the labels and I thought they were right. But your analsis is correct i had a rougue filecontext that i didn't realize was causing the problem so removed and problem seems gone now. hopefully stays that way :) So i'm embarrased sorry for the noise! > Try 'fixfiles -v restore' (and of usually I use restorecon, what's difference to fixfiles if you don't mnind? > > Info for people > > who use it on how to open new ports. If the command I used is the > > right way to do it, then it should be simple duty to add a note about > > it > > as a doc on a readme file or web page associated with the yum > > package. Or in the "yum info" notes! > > It's not a Postfix issue. It's a SELinux issue. SELinux is an *optional* > feature of *some* platforms where Postfix runs, entirely external to > Postfix. Postfix also doesn't come with explanations of pf, ipfw, > iptables, or Cisco ASA configuration. The RPM packages that are > installed by 'yum' never include substantial documentation in the notes > that 'yum info' shows. well I know it's in no way a postfix problem but i thought the packager maintainer should include info on how to make trivial changes to policy if they need to do things like add extra smtpd listener, a common mod. if i was maintaining rpm packages i would think it a helpful for my users to know things like that you clarified that the rules are created by selinux which makes the split of responsibility difficult to track and frustrating for admins :) > > -- 20025 is a very minor mod, > > Yes. SELinux is designed to move the security of Linux away from the > traditional discretionary access control model where minor mods > generally just work because there is nothing prohibiting them towards a > more mandatory access control model where all is prohibited except that > which defined policy allows. The "targeted" policy assembly in the RHEL > family is a reasonable compromise towards the mandatory ideal and it > seems to me that it is correct for it not to allow arbitrary listener > additions. In a system where policy is supposed to overrule software > configuration, ANY TCP listener should require a specific explicit > policy rule. i don't mind that, seems like good choice, but what's missing for people not experts in selinux (esp. if it's forced turned on in default for *everyone*) is some docs by *someone* hosted *somewhere* like tutorial on the simple rule you need to add to open a new smtpd port.... i think it's too much to expect you have to dig around in the port list policy to try to figure out what _t type is being used for postfix rules and then add the right one. too convoluted. > You're making more of this than it is. Assuming that in fact there's a > bug that you've found in the default postfix SELinux policy, you > wouldn't need to replicate and replace the whole base postfix.pp, you'd > need to add a single rule. the point was exactly that, didn't want to replicate anything and also not add another whole policy for something already on the system. but if there is any other problem i guess only way is to add a new local policy with just one rule in it? anyway, i wish the selinux people would read this :) thank you for yoru responses its greatly appreciated you take time to engage with me!
