Re: Website and library packages

[utsl@quic.net]

Would you mind posting a patch? I'd like to see if I can get your modifications
to work in my FreeBSD chroot. 

Thanks,

	---Nathan

On Sun, Jan 20, 2002 at 12:27:23AM +0000, Matthew Garrett wrote:
> On Thu, Jan 17, 2002 at 04:27:33AM +0000, Matthew Garrett wrote:
> > Ok, it turns out that this doesn't look too bad. In shadow-foo/lib we have
> > a stack of code that performs the actual manipulation of the files, with
> > all the utilities using that. There's code there for manipulation of
> > dbm-style passwd files, so it shouldn't be too difficult to hack in code
> > to support the NetBSD password databasesand then just call pw_mkdb
> > afterwards. What we do lose is any ability to use the extended features
> > that are offered over traditional password files, but we keep the ability
> > to use PAM. Combining both sets of features into one set of tools looks
> > like a little more work :)
> 
> Right, as of today I have a working passwd program. Most of the other
> utilities from shadow also work, although I haven't fixed group handling
> yet so addgroup (and hence adduser) aren't happy. This is without PAM -
> I've modified libshadow in the following ways:
> 
> 1) commonio.c now uses the BSD pw_lock and pw_mkdb functions (I spent some
> time trying to figure out why pw_mkdb didn't work in the chroot until I
> looked at the libutil source and found that my assumption that the
> pwd_mkdb utility called the library function was incorrect - instead, the
> library calls the utility. Copied that over into the chroot and everything
> became happy)
> 2) pwio.c uses getpwnam(), and pw_lock() was renamed to pw_filelock() to
> avoid colliding with libutil's pw_lock(). All the utilities had to be
> modified to cope with this.
> 3) putpwent.c was modified to output stuff in the right format
> 
> There's no support for password aging, expiry or user classes, but those
> ought to be relatively easy to add. I'll build a package tomorrow and
> upload it. The code isn't pretty at the moment, and I'm sure it's full of
> horrible race conditions and suchlike, but it's an improvement over having
> no functionality at all :)
> 
> -- 
> Matthew Garrett | mjg59@srcf.ucam.org
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>