abeaver@ads.com (Annadiana Beaver) (12/03/88)
I ran into a bug in 'yppasswd' a few weeks ago, which seemed to be a bit of a variation on the one described by Dimitri. However, in looking into it a bit further, so that I could accurately describe it here, I find that it is most likely part of the same bug. I first saw the problem because a user 'tess' had wished to change their passwd and was given the message: couldn't change password I poked around and found that if I moved the entry for 'tessting', which had a "*" in place of the passwd string, AFTER the entry for 'tess', it was then possible for 'tess' to change their passwd. The account for 'tessting' had had the "*" in place of a passwd string so that noone could log in to the account until they returned from a leave. When there is a passwd string in place of the "*", and the longer entry is BEFORE the shorter entry, yppasswd does exactly as Dimitri described. It eliminates the shorter username. Since 'yppasswd' works as it should when 'tess' is found BEFORE 'tessting' in the passwd file, my "bandaid" for the problem was to move the shorter entry so that it is found first. Question: Why does 'yppasswd' work on userNAME rather than UID? Annadiana Beaver Computer Facilities Advanced Decision Systems
zwicky@pterodactyl.cis.ohio-state.edu (Elizabeth D. Zwicky) (12/03/88)
About yppasswd: We have reason to believe that yppasswd goes through the database using getpwent in a loop instead of getpwuid once. This would result not only in the symptom we saw (speed deteriorates in a geometrical progression as the password file gets larger), but also in the one mentioned where password changes match on substrings. You might be able to avoid it by sorting your password file into reverse alphabetic order. On Hewlett-Packards this problem happens not only in yppasswd but also in finger. You may also have problems with rpc.yppasswdd, which in SunOS 3.5 dies if anyone tries to change a password while the password file is locked. This is a significant problem for us at the beginning of quarters, when users (using yppasswd) and operators (using an account program which locks the password file) are both changing things often. Elizabeth Zwicky (zwicky@cis.ohio-state.edu)
celvin@EE.SURREY.AC.UK (Chris Elvin) (12/10/88)
Dimitri Konstantas mentioned a bug in yppasswd (v7n17). We have also discovered this and another bug in the yellow pages system. Our bug concerns the the function innetgr() which tests whether a user is in a particular net group or not. We have the situation shown below: user name net group name ee87jjs ise87 ee87jjs1 beng87 innetgr() matches users using strncmp() on the user name with strlen(user name) as the length parameter and does not check that further characters may be present in the yellow pages entry. This also occurs when trying to match domain and machine names in innetgr(). Thus innetgr() shows user ee87jjs is in both beng87 and ise87 net groups. I have made a patch to the innetgr() function which overcomes this which I have mailed to sun-spots. I have not had time to investigate yppasswd itself but someone should start shouting at SUN since this is potentially a minefield. Has anybody got a patch for the rest of yellow pages cause I suspect that this bug occurs all over yellow pages. Christopher Elvin, Network Address : celvin@ee.surrey.ac.uk Dept. of Electronic and Telephone : +44 483 571281 ext. 9104 Electrical Engineering Direct line : +44 483 509104 University of Surrey, Telex : +44 859331 Guildford, Fax : +44 483 300803 Surrey, GU2 5XH.
pearce@tycho.yerkes.uchicago.edu (Eric C. Pearce) (12/13/88)
Having just rewritten passwd (the non-YP version), yppasswd most likely
uses unames instead of uids to allow users to share uid's.
It seems to me uid sharing that this is not a good idea and can see only
one application for it. Say a group of users working a the same project
would like to "pool" their disk quotas for the project. Shared uids allow
this (I think). One does have to wonder which user name ls will print and
the quota system will user for the "group".
- Ecp
Eric C. Pearce, Yerkes Observatory, University of Chicago.
pearce@tycho.yerkes.uchicago.edu
pearce%tycho.yerkes.uchicago.edu@oddjob.uchicago.edu