Bug 30424

Summary: Generalization of vipw(8) to lock pwdb while being edited by a script
Product: Base System Reporter: alan
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.3-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff
none
smime.p7s none

Description alan 2001-09-07 23:40:01 UTC
	I have scripts to update accounts, and need to have the password
	file locked while they run to avoid having a user change their
	password at the same time and losing one of the updates.  Since
	vipw already does most of what needs to be done, I've modified it
	so that when invoked as "pw_lock", instead of running vi, it runs
	the specified command, but still does all the locking and database
	updating.

How-To-Repeat: 	N/A
Comment 1 Peter Pentchev 2001-09-08 09:08:06 UTC
On Fri, Sep 07, 2001 at 03:34:37PM -0700, alan@batie.org wrote:
> 
> >Number:         30424
> >Category:       bin
> >Synopsis:       Generalization of vipw to lock pwdb while being edited by a script
> >Originator:     Alan Batie
> >Release:        FreeBSD 4.3-STABLE i386
> >Organization:
> RainDrop Laboratories
> >Environment:
> System: FreeBSD aggie.rdrop.com 4.3-STABLE FreeBSD 4.3-STABLE #3: Wed Sep 5 13:36:38 PDT 2001 root@aggie.rdrop.com:/usr/src/freebsd/sys/compile/AGORA i386
> 
> 
> >Description:
> 	I have scripts to update accounts, and need to have the password
> 	file locked while they run to avoid having a user change their
> 	password at the same time and losing one of the updates.  Since
> 	vipw already does most of what needs to be done, I've modified it
> 	so that when invoked as "pw_lock", instead of running vi, it runs
> 	the specified command, but still does all the locking and database
> 	updating.

Good idea!

[snip]
> + 	if (!(pid = vfork())) {
> + 		execl(argv[0], progname, tempname, (char *)NULL);
> + 		warn("Command '%s' failed", argv[0]);
> + 		pw_error((char *)NULL, 0, 0);
> + 	}

I think you should check pid for -1 here, though..

> ***************
> *** 83,88 ****
> --- 85,95 ----
>   at very large sites could take several minutes.  Until this update
>   is completed, the password file is unavailable for other updates
>   and the new information is not available to programs.
> + .Pp
> + If invoked as
> + .Nm pw_lock
> + , the user database ...

This might be written better as

If invoked as
.Nm pw_lock ,
the user database ...

Other than that, good work!

G'luck,
Peter

-- 
If there were no counterfactuals, this sentence would not have been paradoxical.
Comment 2 Jilles Tjoelker freebsd_committer 2010-07-30 00:50:55 UTC
Is there any reason you need a special option in vipw(8) to run (in
effect) a different editor, when temporarily changing the EDITOR
environment variable would do the same?

Also, the pw(8) utility may be useful, allowing various modifications to
the passwd database more easily.

-- 
Jilles Tjoelker
Comment 3 alan 2010-07-30 01:39:30 UTC
On 7/29/10 4:50 PM, Jilles Tjoelker wrote:
> Is there any reason you need a special option in vipw(8) to run (in
> effect) a different editor, when temporarily changing the EDITOR
> environment variable would do the same?
> 
> Also, the pw(8) utility may be useful, allowing various modifications to
> the passwd database more easily.


Those would have been (and, yes, were available) useful alternatives 9
years ago ;-)

The EDITOR hack makes me nervous for gettings args and stdin to the
script, though I'm pretty sure they would work; pw is probably the
"right" solution to the problem I was solving, though it's inefficient:
I was (actually, still am --- that script is still in use) reading in
the password file, making several updates to it in memory, then writing
it back out.  We're talking numbers you can count on fingers and toes
though, so efficiency really isn't a factor in this case, though it's
conceivable.  Well, I'm not sure an application where it would be a
factor *is* conceivable, and any setup that large would probably be
using a db backend of some sort, but still, that's the sort of operation
where pw_lock is useful, and it's trivial to support.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:35 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped