Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #179417

Re: UID mismatch across systems

From Ross Boylan <rossboylan@stanfordalumni.org>
Newsgroups linux.debian.user
Subject Re: UID mismatch across systems
Date 2017-03-27 02:30 +0200
Message-ID <tpqHL-7SX-1@gated-at.bofh.it> (permalink)
References <tp1gm-6A9-5@gated-at.bofh.it> <tpocV-62P-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sun, Mar 26, 2017 at 2:47 PM, Joshua Schaeffer
<jschaeffer0922@gmail.com> wrote:
>
> On 03/25/2017 03:03 PM, Boylan, Ross wrote:
>
> The problem is that I can't convert to using a shared directory when
> different systems assign different uids to the same named user.  In other
> words, to get to the shared accounts solution I must already have solved the
> problem of mismatching ids.
>
> Not entirely true, NFSv4 has the ability to map uid/gid between systems with
> the rpc.idmapd program, which uses the idmapd.conf configuration files.
>
> The problems are mostly with system users, and I've seen some advice
> indicating such users don't normally go in LDAP.  So excluding would reduce
> the problem, for LDAP, but also leave lots of unsynchronized ids.
>
> What is the issue of unsynchronized system ids? Are you allowing login of
> these system ids? Are they also sharing a filesystem (NFS, CIFS, etc) for
> these system ids? My assumption is that when you say shared directory you
> are talking about $HOME for a normal user. If that's not the case then it
> sounds like you are using an old technique where many systems mount shared
> filesystems to /usr, /usr/share, /opt, etc. I haven't seen that in years as
> disks are quite large enough to handle the space needed for these
> directories.

The main practical problem is with backups, restores and copies that
use numeric ids instead of names.  This includes taking a disk that
was used on one system and using it in another.

Beyond that, I had a general sense that the mismatched ids could cause
trouble.  You're right, I'm not likely to be doing things like ssh'ing
after having assumed a system account id or sharing files owned by
system ids over NFS.  So it may be just the backup/copying that's an
issue.
>
> I'm not sure how much a problem it the mismatches are for NFSv4; I believe
> it allows user/kerberos based authentication, but I'm not sure what that
> means for the uids of the files.
>
> Mismatched ids in NFSv4 will result in a uid/gid of -1, which translates to
> something like 4294967295 (I don't think that's the exact number but it's
> close to 2^32) when you run an ls -l on the NFS mount point.
>
> LDAP is my go to solution for synchronized authorization and central account
> management (I do not use it for authentication, but that is my own personal

I was planning  on using kerberos.  Partly that's because I thought
NFSv4 needed it anyway.

> preference). I advocate it, but I know some people prefer simpler solutions
> depending on the situation. A company of 10 systems can easily avoid all of
> the management, hardware, upkeep, etc of LDAP and use something like NIS,
> Puppet, etc or use no central management at all.
>
> I guess I'm not understanding the core problem. I never put system ids
> (including root) into LDAP, only user's ids. Typing this out, it occurred to
> me that I am assuming you mean a system id is an id of >1000 (in Debian). If

I mean ids < 1000.  1000+ seems to be for users on my systems.  On my
systems it's 100-124 that have the problems.

> you are talking about some generic account that is not an actual system ID,
> but is not used by a specific user, then yes you have to find a way to
> synchronize and/or transfer the account. I would simply create the account
> in LDAP and then transfer all ownership of processes and files to that new
> account (as you already stated).
Are you saying there is a way to change the uid/gid of a process that
is already running from the outside?  Does usermod do that if you
change the uid?

My concern is that if I change file uids existing processes will gag
and, worst case, the system becomes  non-functional even on reboot.*
This seems particularly acute with systemd.  I know I can shutdown
most services, change ids, and restart them.  But I have the
impression that the ones associated with systemd, and maybe some
others like messagebus, are essential and have to be left running.
And I am accessing the systems via ssh, and so changing the ssh u/gid
seems especially dicey.

*It just occurred to me I could temporarily make permissions more
permissive, or add group permissions, to avoid getting locked out.

Ross

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

UID mismatch across systems "Boylan, Ross" <Ross.Boylan@ucsf.edu> - 2017-03-25 22:20 +0100
  Re: UID mismatch across systems deloptes <deloptes@gmail.com> - 2017-03-26 11:00 +0200
    Re: UID mismatch across systems Ross Boylan <rossboylan@stanfordalumni.org> - 2017-03-26 20:10 +0200
      Re: UID mismatch across systems deloptes <deloptes@gmail.com> - 2017-03-26 20:30 +0200
        Re: UID mismatch across systems Ross Boylan <rossboylan@stanfordalumni.org> - 2017-03-26 22:10 +0200
          Re: UID mismatch across systems deloptes <deloptes@gmail.com> - 2017-03-26 23:30 +0200
  Re: UID mismatch across systems Joshua Schaeffer <jschaeffer0922@gmail.com> - 2017-03-26 23:50 +0200
    Re: UID mismatch across systems Ross Boylan <rossboylan@stanfordalumni.org> - 2017-03-27 02:30 +0200
      Re: UID mismatch across systems Joshua Schaeffer <jschaeffer0922@gmail.com> - 2017-03-27 05:00 +0200
        Re: UID mismatch across systems Ross Boylan <rossboylan@stanfordalumni.org> - 2017-03-29 00:30 +0200

csiph-web