Date: Wed, 26 Mar 2003 07:29:22 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: questions@freebsd.org Subject: Re: File owner name not updated. Message-ID: <20030326072922.GA5568@happy-idiot-talk.infracaninophi> In-Reply-To: <DEE7FC6C-5F57-11D7-95E4-000A959CEE6A@pursued-with.net> References: <DEE7FC6C-5F57-11D7-95E4-000A959CEE6A@pursued-with.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030326072922.GA5568>