Re: Building rpms in mock

On 2023-12-22 at 19:37 -0500, Sam Varshavchik wrote:
> Zenon Panoussis writes:
> 
> > The more I think about it, the more I think it would make
> > a lot of sense to ask for a statically allocated uid:gid
> > for courier and fix the user:group to that. It would have
> > the benefit of all rpm installations being identical in
> > this respect and smoothly upgradable without breakages
> > such as a daemon:daemon upgrade of a courier:courier
> > installation or vice versa not starting because all the
> > certificates in /usr/lib/courier/share/ are chmod 600 to
> > the wrong user:group.
> >
> > 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
> 
> I gave this some thought.
> 
> It's beyond dispute that a statically allocated uid:gid is, in general, the  
> right solution. But that's going to seriously muck things up for everyone  
> who already jumped in the boat and is running Courier as mailuser:mailgroup.

courier doesn't need a static mapping of uid:gid

Debian has been patching courier to dynamically resolve them for a long
time.

Then, some years ago, I updated that to make it more compatible with
default configuration, so that a uid of 0 meant "figure out on runtime.
https://salsa.debian.org/debian/courier/-/blob/master/debian/patches/0024-Dynamically-resolver-mailuid-and-mailgid-on-runtime-.patch

This was then upstreamed, even removing the possibility of setting them
at build time (dfbffea04067f0d49488454d051334f82295d9d5 & de8102845637c
813e411fd0ca1f545497358b109 at libs).


You obviously need the username to match (or have another user with the
expected one and same uid). It would be better to handle that
automatically, of course, but I don't think it would be a stretch to
require that someone reocompiling them doesn't use packages with
mismatching pairs of user:group.





_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users