About passwd, deluser and delgroup

[Rob Landley]

On Saturday 08 April 2006 5:03 pm, Tito wrote:
> On Saturday 8 April 2006 22:00, Rob Landley wrote:
> > On Saturday 08 April 2006 2:33 am, Tito wrote:
>
> snip
>
> > Ok, I've already changed all this in my version to have no relation to
> > the code you're showing me now.  Just FYI...
>
> ?!? I don't understand this sentence..... ?!?
> Why there should be no relation, maybe you think i'll sue you
> for copyright infringement???
>
> ;-P

No, I'm just saying you're talking about modifications to a section of code 
I've already completely changed (shrunk, simplified, merged a couple of code 
paths, and redid how it handled concurrency).  These modifications aren't 
relative to what I'm working on now, and most of them don't even conceptually 
apply.

> > The locking is _entirely_ unnecessary if all updates are done via the
> > "hardlink to create backup, create new version O_EXCL with known name, mv
> > new name to original name" method.  It's 100% bloat.
>
> OK, fine.
> I'm only suggesting to create a libbb function as this code could be shared
> between at least passwd, deluser, delgroup (and probably also adduser,
> addgroup as they also scribble in /etc/*passwd files).

That's a good idea.  I agree, it should be shared.

> > What other programs are
> > going to be modifying /etc/passwd and /etc/shadow?
>
> Multiple concurrent instances of passwd, deluser, and adduser for example.

Busybox instances, or non-busybox instances?

As long as everything busybox does is consistent, then busybox can be 
prevented from interfering with other instances of busybox without file 
locking.  If we're talking about protecting access from programs other than 
busybox, your average text editor is likely to be the #1 candidate and it's 
not likely to care about file locking much either.

Rob
-- 
Never bet against the cheap plastic solution.