On Tue, Mar 25, 2003 at 11:35:42PM -0800, Kevin Stevens wrote:
On Tuesday, Mar 25, 2003, at 23:29 US/Pacific, Matthew Seaman wrote:
Two things occur to me:
i) Did root use vipw(8) to edit the passwd database, or otherwise
run:
# cap_mkdb /etc/master.passwd
In the last episode (Mar 25), Kevin Stevens said:
On Tuesday, Mar 25, 2003, at 23:29 US/Pacific, Matthew Seaman wrote:
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
On Tue, Mar 25, 2003 at 11:44:52PM -0800, Kevin Stevens wrote:
On Tuesday, Mar 25, 2003, at 23:29 US/Pacific, Matthew Seaman wrote:
Two things occur to me:
i) Did root use vipw(8) to edit the passwd database, or otherwise
run:
# cap_mkdb /etc/master.passwd
On Wednesday, Mar 26, 2003, at 00:13 US/Pacific, Matthew Seaman wrote:
Interesting. I can reproduce exactly what you're seeing:
...
However, running pwd_mkdb(8) seems to cure the problem very
effectively:
...
Looks like a bug to me...
Cheers,
Matthew
Thanks very much Matthew and Dan for
I had this problem several months ago, submitted a bug report on it,
and promptly forgot about it. I'm now seeing the same issue in 5.0,
and want to delve a little deeper to see if this is expected behavior
or not.
I created a user, let's call him fred, which was assigned uid 503. The
user
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,
and promptly forgot about it. I'm now seeing the same issue in 5.0,
and want to delve a little deeper to see if this is expected behavior
or not.
I created
On Tuesday, Mar 25, 2003, at 23:29 US/Pacific, Matthew Seaman wrote:
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
On Tuesday, Mar 25, 2003, at 23:29 US/Pacific, Matthew Seaman wrote:
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
