I really do not know whether is this possible in Portage but i will try :-) Dovecot installs LDA called deliver to /usr/libexec/dovecot/deliver. In some circumstances (when using separate UIDs per mailbox/domain/whatever) you have to make it suid root. It is also wise to change permissions of deliver to be executable only by user running SMTP eg. postfix:postfix. So it would be nice if ebuild preserve the permissions/ownership of this file. I can also try to provide a patch if it is possible and someone give me a quick hint :-) Reproducible: Always
Sorry, typo in subject.
The suid USE flag now installs deliver suid. It's up to you to manage more permissions.
Sorry, but I think that this is not a proper solution. Right solution would be to leave permissions/ownership of deliver untouched. Taken from Dovecot Wiki "deliver isn't designed to be run as setuid-root, so you should take extra steps to make sure that untrusted users can't run it and potentially gain root privileges" so there should be at least big ewarn about this and about changing permissions of deliver during update because it is making the Dovecot installation less secure (i think that users will not consider this as unneeded babysitting). As I already mentioned, I am free to make the patch if you think that it is possible.
Yes, I did read that - however that is what you are asking, otherwise I can confused. OK, given the current limitations of portage, the choices are 1) no choice, no suid 2) some choice - suid USE flag to make deliver suid. Aside from that, patches to either the ebuild or portage are welcome.
Sorry for misunderstood, I was asking if it is possible to preserve permissions of "deliver" when old version is found (including owner and mode)? I do not know current limitations of Portage and that's why I was asking...
I don't know of such a portage feature. We would need one as the tools to work out group/owner of existing files are very much platform dependant (ie, the stat userland function)
Other than waiting for bug #141619 you could check the permissions of the existing binary in preinst and restore those permissions in postinst (but that's just a nasty workaround). *** This bug has been marked as a duplicate of bug 141619 ***
