On Mon, Feb 12, 2024 at 01:50:27PM +0300, Anton Farygin wrote:
> On 12.02.2024 13:34, Dmitry V. Levin wrote:
> > Всё обстоит несколько иначе.
> 
> Ну да, но смысл от этого особо не меняется.
> 
> sysctl этот, судя по документации, для каких-то старых файловых систем
> нужен:
> 
> https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid

NFS с его логикой ремаппинга рута трудно назвать старой файловой
системой. :)

Более того, письмо Димы с цитатой git grep по ядру меня сподвигло узнать
вот об этом:

user_namespaces(7):
   Unmapped user and group IDs
       There  are various places where an unmapped user ID (group ID) may be exposed to user
       space.  For example, the first process in a new user namespace may call getuid(2) be‐
       fore a user ID mapping has been defined for the namespace.  In most  such  cases,  an
       unmapped  user  ID is converted to the overflow user ID (group ID); the default value
       for the overflow user ID (group ID) is 65534.  See the descriptions of /proc/sys/ker‐
       nel/overflowuid and /proc/sys/kernel/overflowgid in proc(5).

       The cases where unmapped IDs are mapped in this fashion include system calls that re‐
       turn user IDs (getuid(2), getgid(2), and similar), credentials passed over a UNIX do‐
       main socket, credentials returned by stat(2), waitid(2), and the System V  IPC  "ctl"
       IPC_STAT  operations,  credentials  exposed  by  /proc/pid/status  and  the  files in
       /proc/sysvipc/*, credentials returned via the si_uid field in the siginfo_t  received
       with  a signal (see sigaction(2)), credentials written to the process accounting file
       (see acct(5)), and credentials returned with POSIX message queue  notifications  (see
       mq_notify(3)).