Date: Wed, 26 Mar 2003 07:59:27 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: questions@freebsd.org Subject: Re: File owner name not updated. Message-ID: <20030326075927.GB5568@happy-idiot-talk.infracaninophi> In-Reply-To: <8C8C94D2-5F5D-11D7-95E4-000A959CEE6A@pursued-with.net> References: <20030326072922.GA5568@happy-idiot-talk.infracaninophi> <8C8C94D2-5F5D-11D7-95E4-000A959CEE6A@pursued-with.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--s2ZSL+KKDSLx8OML
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Mar 25, 2003 at 11:35:42PM -0800, Kevin Stevens wrote:
>=20
> On Tuesday, Mar 25, 2003, at 23:29 US/Pacific, Matthew Seaman wrote:
>=20
> >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.
>=20
> Just used the pw command. However, note that this symptom persisted=20
> for over 24 hours. Last time it happened (on a 4.7 system) it=20
> persisted for several days if I recall, before I noticed/corrected it.
Of course, when I said cap_mkdb(8), astute readers will immediately
have realised that I meant to say pwd_mkdb(8) --- it's too early in
the morning here. However all of the system supplied password
management commands such as pw(8) and vipw(8) will automatically run
pwd_mkdb(8) as necessary. pwd_mkdb(8) will generate the /etc/passwd
file out of the /etc/master.passwd file, so checking that the UID
change has propagated from the master would be a useful datapoint.
=20
> > 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.
>=20
> Correct.
>=20
> > 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.
>=20
> Right, and this is a standalone system (which is why I'm manually=20
> syncing up the uids in the first place).
In which case I'd expect that the intended change should take effect
straight away.
=20
> >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),=20
> >eg:
> >
> > % perl -e 'print scalar getpwuid(503), "\n";'
Yet another alternative is:
% id -P 503
or=20
% id -P fred
=20
> Got it. I think what I'll do is create a dummy user with the same=20
> conditions and let it persist for awhile so we can experiment with it.
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
--s2ZSL+KKDSLx8OML
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+gV3fdtESqEQa7a0RAuyZAKCQBGwzvTlu9PqTfDW3S+eOV237aQCgldWU
EML7kW6LumM/sm2q3Umbsu4=
=kTDC
-----END PGP SIGNATURE-----
--s2ZSL+KKDSLx8OML--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030326075927.GB5568>