[Pkg-shadow-devel] fixed uid for postgres

[Colin Watson]

On Fri, Oct 31, 2025 at 01:19:50PM +0300, Олег Самойлов wrote:
>   Let me explain, why PostgreSQL in needed in fixed uid. PostgreSQL don't
>   need it when it run in simple setup, but common practice is to create high
>   availability cluster or other high availability solutions, when servers
>   must exchange files between each other. And common practice is to use NFS
>   for this purpose, why not? And in such case all files must be visible as
>   belonged to user postgres on all servers. So there is two variants.

I have to say that I've never seen this in high-availability setups 
myself (I've never been more than a casual DBA, but I have 10+ years of 
experience developing applications on top of PostgreSQL, and most of 
that has been in environments that required minimizing downtime).  
https://www.postgresql.org/docs/current/continuous-archiving.html does 
mention it in passing, but personally I can't say I'd want to have NFS 
as a critical component of my database cluster's redundancy; its failure 
modes are just too annoying.

I typically prefer using logical streaming replication rather than 
WAL-shipping to keep replicas up to date with the primary.  WAL-shipping 
is still useful for continuous backups with point-in-time recovery, and 
as a fallback.  If your primary and replicas are close enough in network 
terms to make NFS viable, then arranging direct connectivity for 
streaming replication shouldn't normally be difficult.

But if your organization really wants to deal with keeping replicas up 
to date using WAL-shipping over NFS, I won't stand in your way!

>   1.  NFS v.4 can resolve a text user name. But do it not by NFS server
>   itself, by the external daemon "idmap", if I understand correctly, it can
>   be abscent.  v.3 don't work with text usernames at all, only with uid. Our
>   sysadmins insists that our China NFS storage don't support text usernames.
>   I don't believe them. Also they insist that rise and support idmap only
>   for one user postgres is overengineering and just setup the same uid on
>   all servers in cluster is much more simple and reliable solution. I agree
>   with them here.
>    
>   2. Okey, fixed uid. They choose fixed uid=418. I think this is incorrect
>   and violate Debian Policy, fixed uid must be from the range 63000-64999.
>   Or, from reserved range, for instance, 65432. But they insist, that fixed
>   uid=418 is much more reliable solution if considering potential conflicts.
>   So I just want to do things right. If you will reject I will not have a
>   choice other then permit to violate Debian Policy. It just works.

It's true that this ID is within a range that the Debian Policy Manual 
specifies as being for dynamically-allocated system users and groups.  
However, Debian policy describes policy requirements for the Debian 
distribution and for creating Debian packages.  A site can't violate 
Debian policy by the way in which it deploys Debian; that's just a 
category error.

You should also note that the Debian Policy Manual explicitly says "many 
sites allocate users and/or local system groups starting at 100", and 
anticipates that in its design.

When doing site-local allocation like this, you need to think the other 
way round from the text in the Debian Policy Manual: your consideration 
isn't "what may a package do to avoid conflicting with other packages 
and local policies", but rather "what can we do that a package won't 
conflict with by accident"?  In practice, this means that it's important 
to use one of the dynamically-allocated ranges.  Any of the ranges 
100-999, 1000-59999, or (if your system can tolerate 32-bit user IDs) 
65536-4294967293 is fine.  63000-64999 would not be fine; that's within 
a range (60000-64999) that's statically allocated by Debian, so your 
sysadmins are correct to say that they should not use it.  I suppose 
65432 would probably be OK, but I don't see any particular reason to 
prefer it over 418.

If your site wants to allocate a fixed ID for the postgres user, then I 
see no problem with that provided that it's in a dynamically-allocated 
range and is reliably created on each system before the PostgreSQL 
packages are installed.  (Or, technically, before any packages outside 
the base system are installed; but for an ID as high as 418 this 
shouldn't be a problem in practice.)  Debian packages doing dynamic ID 
allocation will notice that the ID already exists, and no Debian package 
should be hardcoding ID 418, so there's no conflict here.

Cheers,

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]