Subject: pwlock and sound stuff

From: [email-masked]

Well, these two things are unrelated, but they've both been on my mind for
a while, so here goes.

    First of all, I was wondering what the real use of pwlock is.  I was
talking with someone, and the only reason that we can come up with for it
locking the password file is that if someone else knows your password and sees
you in passwd, they could run passwd and change your passwd first.  Seems kind
of silly to me, considering they could just kill the process and do it anyway.
I'm assuming that's not the reason it works the way it does, though.  So I was
wondering, why couldn't there be record locking instead of database locking,
or no locking except right before the write, and an unlock right after the
write?  Seems like it would be better that way as more people could change
their passwords at once.  It can be a problem if the entire password file is
locked and someone else wants to change their password.

    Ok, I'm currently running FreeBSD 1.1.5.1, until the release of NetBSD
1.0.  I was wondering if there is someone already working on porting support
for the rest of the sound cards to NetBSD.  The reason I ask is they are
already ported to FreeBSD, and it should be trivial (I hope) to port them the
rest of the way to NetBSD, and if no one else is working on it, I'd like to
take a crack at it! :-)

-matt

-- 
Matthew C. Mead -- System/Network Administration, User Support, Software Devel.
Virginia Tech Center for Transportation Research
Work Related: [email-masked] | All Other: [email-masked]
WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead

---

From: Chief Anarchic Officer <[email-masked]>

#define AUTHOR "[email-masked] ([email-masked])"

/*
 *     Well, these two things are unrelated, but they've both been on my mind for
 * a while, so here goes.
 * 
 *     First of all, I was wondering what the real use of pwlock is.  I was
 * talking with someone, and the only reason that we can come up with for it
 * locking the password file is that if someone else knows your password and sees
 * you in passwd, they could run passwd and change your passwd first.  Seems kind
 * of silly to me, considering they could just kill the process and do it anyway.
 * I'm assuming that's not the reason it works the way it does, though.  So I was
 * wondering, why couldn't there be record locking instead of database locking,
 * or no locking except right before the write, and an unlock right after the
 * write?  Seems like it would be better that way as more people could change
 * their passwords at once.  It can be a problem if the entire password file is
 * locked and someone else wants to change their password.
 * 

Matthew,

Take into account that things like "chfn" and "chsh" (or passwd -{f,s} --
I haven't run my BSD lately!) (not to mention "vipw") also change the
passwd and/or mpasswd files.   While "passwd" doesn't change the length
of a record, if you change your finger name or your shell, the length of
the password record may change.  In short, records are of variable length
inside the {m,}passwd files.

Were they constant length, this would not be a problem.

(Interesting, though, that there is actual locking on the file instead
 of using /etc/ptmp as the lock and the working file at the same time...)

 * -- 
 * Matthew C. Mead -- System/Network Administration, User Support, Software Devel.
 * Virginia Tech Center for Transportation Research
 * Work Related: [email-masked] | All Other: [email-masked]
 * WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead
 * 
 * 
 * 
 * 
 * 
 */

#undef AUTHOR	/* "[email-masked] ([email-masked])" */

--
 _______Wizardry is dead._____ _____WHO: Greywolf (my nameplate even says so)
/ ___\ _ \ __\ V / \  / /__ \| | __/WHAT: UNIX System Mangler...er, Admin
\ \| |   < _| ` ' \ '` / \/ /|_| _/ WHERE: Autodesk, Inc.  3 Harbor Dr.
 \___|_|\_\__\|_|  \/\/ \__/___/_|  Sausalito, CA 94965 (415) 332-2344 x4219
	see also: [email-masked]