Bug 30424 - Generalization of vipw(8) to lock pwdb while being edited by a script
Summary: Generalization of vipw(8) to lock pwdb while being edited by a script
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 4.3-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-09-07 23:40 UTC by alan
Modified: 2018-01-03 05:13 UTC (History)
0 users

See Also:


Attachments
file.diff (3.78 KB, patch)
2001-09-07 23:40 UTC, alan
no flags Details | Diff
smime.p7s (5.13 KB, application/pkcs7-signature)
2010-07-30 01:39 UTC, alan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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