From owner-freebsd-questions@FreeBSD.ORG Tue Mar 25 23:29:28 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67B9337B404 for ; Tue, 25 Mar 2003 23:29:28 -0800 (PST) Received: from smtp.infracaninophile.co.uk (happy-idiot-talk.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56ABD43FAF for ; Tue, 25 Mar 2003 23:29:25 -0800 (PST) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [127.0.0.1]) h2Q7TMpQ005972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Mar 2003 07:29:22 GMT (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost)h2Q7TM4e005971 for questions@freebsd.org; Wed, 26 Mar 2003 07:29:22 GMT Date: Wed, 26 Mar 2003 07:29:22 +0000 From: Matthew Seaman To: questions@freebsd.org Message-ID: <20030326072922.GA5568@happy-idiot-talk.infracaninophi> Mail-Followup-To: Matthew Seaman , questions@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: Re: File owner name not updated. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 07:29:30 -0000 X-List-Received-Date: Wed, 26 Mar 2003 07:29:30 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2003 at 10:55:03PM -0800, Kevin Stevens wrote: > I had this problem several months ago, submitted a bug report on it,=20 > and promptly forgot about it. I'm now seeing the same issue in 5.0,=20 > and want to delve a little deeper to see if this is expected behavior=20 > or not. >=20 > I created a user, let's call him fred, which was assigned uid 503. The= =20 > user directory was created and assigned to owner fred and group wheel. = =20 > All ok. Later that evening, root changed the uid for fred to 502 (for=20 > compatibility with other systems). The problem isn't that the=20 > directory owner didn't automatically change to uid 502 - I expected to=20 > have to change it manually. What I wasn't prepared for is that a ls=20 > -al still showed the owner as fred, which was now assigned to uid 502. = =20 > ls -lan properly showed the owner as still being 503. >=20 > So, I'm open to correction, but it seems to me that something's broken.= =20 > If user fred used to be 503, but is now 502 (there is no user 503=20 > now), I don't see how it can be correct for ls to still report fred as=20 > the owner of files/directories. I expected the reporting to change to=20 > just show the numeric uid, but I'm not picky about that. >=20 > I have no idea whether this is a problem with the ls command, with the=20 > filesystem, with some index of ownership/permissions, or something else= =20 > entirely. Suggestions? Two things occur to me: i) Did root use vipw(8) to edit the passwd database, or otherwise run: # cap_mkdb /etc/master.passwd when the UID was changed? It's the value in the hashed database cap_mkdb(1) builds that is used by the system. Updating that should have instantaneous effect. ii) You haven't said anything about what the source of your password data is, which probably means you're just using the flat file password database and not anything like NIS or LDAP. If you are using a distributed database, then a degree of latency while changes get propagated around the servers is to be expected. However, that shouldn't take any more than a few minutes in a well configured system. The problem is not with the ls(1) command per se. It's the underlying system library functions such as getpwuid(3) which do the translation between numeric UIDs and usernames that are the seat of the problem. You can see that by running some other command that uses getpwuid(3), eg: % perl -e 'print scalar getpwuid(503), "\n";' Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+gVbSdtESqEQa7a0RAn6zAJ9cFoc4LJy7v+RJhNpS+mn9aojAaACeKXdJ dGhbeOTuxbWnYmldRVhJ/Y0= =C/jM -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT--