Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • jwt_encode_inconsistencies
  • recovery-code-pwhash
  • incremental-sync
  • redis-rate-limits
  • typehints
  • v1.2.x
  • v1.x.x
  • v1.1.x
  • feature_invite_validuntil_minmax
  • Dockerfile
  • v1.0.x
  • roles-recursive-cte
  • v2.3.1
  • v2.3.0
  • v2.2.0
  • v2.1.0
  • v2.0.1
  • v2.0.0
  • v1.2.0
  • v1.1.2
  • v1.1.1
  • v1.0.2
  • v1.1.0
  • v1.0.1
  • v1.0.0
  • v0.3.0
  • v0.2.0
  • v0.1.5
  • v0.1.4
  • v0.1.2
31 results

user.py

Forked from uffd / uffd
Source project has a limited visibility.
  • Julian's avatar
    53c06069
    New UID/GID allocation approach · 53c06069
    Julian authored
    Previously Unix UIDs/GIDs were allocated by using the highest used ID + 1.
    This caused ID reuse when the newest user/group was deleted. In addition, the
    implementation did not work on MariaDB (at all, it was not possible to create
    users/groups).
    
    The new approach accounts for all IDs ever used regardless of whether or not
    users/groups are deleted. It always allocates the lowest ID in the configured
    range that was never used.
    
    Aside from the different allocation algorithm, this change introduces a
    generic locking mechanism and prerequisites for testing migration scripts.
    53c06069
    History
    New UID/GID allocation approach
    Julian authored
    Previously Unix UIDs/GIDs were allocated by using the highest used ID + 1.
    This caused ID reuse when the newest user/group was deleted. In addition, the
    implementation did not work on MariaDB (at all, it was not possible to create
    users/groups).
    
    The new approach accounts for all IDs ever used regardless of whether or not
    users/groups are deleted. It always allocates the lowest ID in the configured
    range that was never used.
    
    Aside from the different allocation algorithm, this change introduces a
    generic locking mechanism and prerequisites for testing migration scripts.