Design for extensible passwd[/shadow?] db support

Design for extensible passwd[/shadow?] db support

[Rich Felker]

Presumably at some point, musl will be used in environments where it's
not feasible to have the entire user database in a flat password file.
Despite NIS being hideous, largish institutions use it for this
reason; presumably LDAP is a much better option, and there may be
other options still I'm not aware of.

What I'm looking for is a way to allow musl to access user data that's
not provided with flat files in /etc, but without bloating musl or
introducing dependencies on abominations like RPC.

The idea I have is to add a single lookup method to musl, whereby it
can query a local daemon of some sort for user information in a clean,
simple protocol. Such a daemon can in turn translate to NIS, if
desired, or to SQL db queries, or to whatever back-end the admin wants
to use. I'm fairly settled on this general approach, but since I'm not
at all familiar with the existing approaches, I'd like to seek some
further input.

The first main question is what protocol to use. One really simple
choice would be a plain text protocol where the name/uid of requested
user is sent over a socket (probably a datagram unix socket) and the
response comes back in standard colon-delimited passwd format for the
existing passwd code to parse. This seems very clean, but as far as I
know it doesn't have any existing implementations.

Alternatively, we could make musl speak an existing query language
(e.g. LDAP) directly, such that it could interface with any existing
server out there that speaks the chosen protocol, or with a proxy that
translates to other protocols like NIS.

Any thought on the pros and cons of these or other appraches?

Rich

Re: Design for extensible passwd[/shadow?] db support

[Jeremy Huntwork]

On Sunday, August 12, 2012 at 1:38 AM, Rich Felker wrote:
> Any thought on the pros and cons of these or other appraches?
> 

This sounds like it should be a feature of the whole 'new platform' suggestion you made on this list earlier, which I'd still like to see gain some traction and definition.

If it is a locally running daemon that resolves queries to some specified format - what would be the fallback in case that daemon is not running or fails to launch?

JH

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Sun, Aug 12, 2012 at 11:16:28AM -0400, Jeremy Huntwork wrote:
> On Sunday, August 12, 2012 at 1:38 AM, Rich Felker wrote:
> > Any thought on the pros and cons of these or other appraches?
> > 
> 
> This sounds like it should be a feature of the whole 'new platform'
> suggestion you made on this list earlier, which I'd still like to
> see gain some traction and definition.

Yes and no. I think most users of our 'new platform' for non-server
purposes would typically have 1-2 non-root users and thus no need for
fancy user lookups. This sort of thing is needed for university and
corporate use where you might easily have 10k-100k users and want to
unify the user database (username/uid mappings) across all systems in
your institution.

> If it is a locally running daemon that resolves queries to some
> specified format - what would be the fallback in case that daemon is

getpwnam/getpwuid would simply fail. This is not unlike what happens
when the NIS server is not reachable anyway. It could of course still
scan /etc/passwd first, which would get users like nobody/daemon/etc.

> not running or fails to launch?

"Not running" and "fails to launch" don't make sense as separate cases
unless you're thinking of some FDO-style monstrosity where daemons are
launched as users lazily the first time they're needed. I'm not
considering code to auto-launch daemons, just using a daemon that the
admin would be responsible for starting if using this kind of setup.

Rich

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Sun, Aug 12, 2012 at 01:38:02AM -0400, Rich Felker wrote:
> The first main question is what protocol to use. One really simple
> choice would be a plain text protocol where the name/uid of requested
> user is sent over a socket (probably a datagram unix socket) and the
> response comes back in standard colon-delimited passwd format for the
> existing passwd code to parse. This seems very clean, but as far as I
> know it doesn't have any existing implementations.
> 
> Alternatively, we could make musl speak an existing query language
> (e.g. LDAP) directly, such that it could interface with any existing
> server out there that speaks the chosen protocol, or with a proxy that
> translates to other protocols like NIS.

A third approach: using the nscd protocol used by glibc/nss. This
would allow musl-linked binaries running as guests on glibc-based
systems with nscd to perform user lookups through whatever service the
host system was using, without any further configuration. The glibc
nscd daemon would not be useful itself on musl-based systems, since it
depends on glibc/nss, but a drop-in clone for it could easily be
written and later fleshed-out with support for NIS, LDAP, and any
other potentially-interesting user database backends.

If folks think this third option is a good one, we'll need to dig up
(or reverse engineer..?) specs on how the nscd protocol works. It
might be a good idea to do this first before making a decision anyway,
since if the protocol is bad enough (bloat, robustness failures, etc.)
we might need to pick something else even if it does have other good
qualities..

Rich

Re: Design for extensible passwd[/shadow?] db support

[Arvid E. Picciani]

On Sun, 12 Aug 2012 01:38:02 -0400, Rich Felker wrote:

> What I'm looking for is a way to allow musl to access user data 
> that's
> not provided with flat files in /etc,

I'm not sure why user auth is in libc in the first place.
These things change, and a libc is not something i would
see as a layer where system design should happen.


> [..] abominations like RPC. [..]

This assumes RPC is the way it is out of bad intent, while it really
grew out of exactly the same requirements. Things don't get better
by rewriting them without changing the design.


> [..] can query a local daemon [..]

> The first main question is what protocol to use.

well, so use the existing rpc. it fullfills the given requirements,
and is compatible with the stuff out there.


> Alternatively, we could make musl speak an existing query language
> (e.g. LDAP) directly

And pull even more policy into libc? Then everyone has to patch
libc to adapt to the local ldap layout? or another config?

There is a need for the things you want to do here, but i think
this is the line where it's time to go into higher layers.


-- 
Arvid E. Picciani

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Sun, Aug 12, 2012 at 09:10:16PM +0200, Arvid E. Picciani wrote:
> On Sun, 12 Aug 2012 01:38:02 -0400, Rich Felker wrote:
> 
> >What I'm looking for is a way to allow musl to access user data
> >that's
> >not provided with flat files in /etc,
> 
> I'm not sure why user auth is in libc in the first place.

This is not auth, it's just lookups. Translating uids to usernames and
back.

> >[..] can query a local daemon [..]
> 
> >The first main question is what protocol to use.
> 
> well, so use the existing rpc. it fullfills the given requirements,
> and is compatible with the stuff out there.

Not an option. It's massively bloated and full of security issues.
There is a legitimate need for what NIS provides, but doing it with
NIS and the RPC system is backwards and stupid. Putting this
backwardsness in libc just creates more cost for people who want to do
it right.

> >Alternatively, we could make musl speak an existing query language
> >(e.g. LDAP) directly
> 
> And pull even more policy into libc?

I'm not sure how this is adding policy. I consider the other solution
glibc chose, nss, to be policy. It forces your apps to have dynamic
loader support in them, forces you to have config files in place and
shared libraries present in hard-coded paths, etc. My intent is to
minimize any such requirements, and leave them at absolute zero except
for people who need giant specially-backed user databases.

> Then everyone has to patch
> libc to adapt to the local ldap layout? or another config?

It's the intent that nobody should ever have to patch libc for the
sake of accessing their user database. That's what this thread is
about. I'm not familar with how LDAP is used in the wild for this
purpose, or if it even is, so I don't know how easy it would be to
directly interface with diverse existing LDAP servers, but it seems
like it would be a reasonable, simple proxy language for lookups,
whereby any customization could go in the proxy.

See my later post about nscd; it might be a better choice.

> There is a need for the things you want to do here, but i think
> this is the line where it's time to go into higher layers.

I don't follow. What alternative are your proposing?

Rich

Re: Design for extensible passwd[/shadow?] db support

[Arvid E. Picciani]

On Sun, 12 Aug 2012 16:56:43 -0400, Rich Felker wrote:

> I don't follow. What alternative are your proposing?


push user lookup up the stack and force ancient code to link in the 
high level lib.

imo, getpwent and the link don't belong into libc. They're only there 
because ancient unix
systems had a lot of tools that shared that functionality and an extra 
lib would seem
bloat for the little functionality they offered (basicly, it's a shared 
/etc/passwd parser,
not a user lookup per se). Then glibc wanted more then that, out of a 
real need, and crammed
it into libc as well, because of the inability to break compatibility.
Now, musl _can_ break compatibility with GNU/Linux. Especially if it's 
just "link against another lib".

Then you can go to full lengths and rebuild the whole idea of user 
lookup, auth, etc.
Another grief i have with PAM is that it is orthogonal to libc.

For a dynamic loaded system, if you design the interface carefully, 
this means you can exchange
the auth/user/whatever lib with something else at the packaging level.
For a static linked system, it makes no difference at all.


-- 
Arvid E. Picciani

Re: Design for extensible passwd[/shadow?] db support

[Luca Barbato]

On 8/13/12 11:41 AM, Arvid E. Picciani wrote:
> On Sun, 12 Aug 2012 16:56:43 -0400, Rich Felker wrote:
>
>> I don't follow. What alternative are your proposing?
>
>
> push user lookup up the stack and force ancient code to link in the high
> level lib.

> Now, musl _can_ break compatibility with GNU/Linux. Especially if it's
> just "link against another lib".

I do not see why.

lu

Re: Design for extensible passwd[/shadow?] db support

[Kurt H Maier]

On Mon, Aug 13, 2012 at 02:27:22PM +0200, Luca Barbato wrote:
> 
> I do not see why.
> 

Because it's slightly ridiculous to force some specific auth methodology
down the hatch when it's completely unnecessary.

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Mon, Aug 13, 2012 at 11:41:47AM +0200, Arvid E. Picciani wrote:
> On Sun, 12 Aug 2012 16:56:43 -0400, Rich Felker wrote:
> 
> >I don't follow. What alternative are your proposing?
> 
> push user lookup up the stack and force ancient code to link in the
> high level lib.

"Intentionally break or omit a required standard interface in POSIX
and require every application needing the functionality to pull in
some third-party library" is not a plan that sounds appealing to me.

> imo, getpwent and the link don't belong into libc. They're only

Well that's up to the Austin Group, not you. We implement POSIX.
Unlike glibc, which (used to) implement Drepper's idea of what POSIX
should be changed to. Thankfully now that's changing.

> there because ancient unix
> systems had a lot of tools that shared that functionality and an
> extra lib would seem
> bloat for the little functionality they offered (basicly, it's a
> shared /etc/passwd parser,
> not a user lookup per se). Then glibc wanted more then that, out of
> a real need, and crammed
> it into libc as well, because of the inability to break compatibility.
> Now, musl _can_ break compatibility with GNU/Linux. Especially if
> it's just "link against another lib".
> 
> Then you can go to full lengths and rebuild the whole idea of user
> lookup, auth, etc.
> Another grief i have with PAM is that it is orthogonal to libc.
> 
> For a dynamic loaded system, if you design the interface carefully,
> this means you can exchange
> the auth/user/whatever lib with something else at the packaging level.
> For a static linked system, it makes no difference at all.

Making /bin/ls depend on dynamic loading modules is a bit
disgusting...

Rich

Re: Design for extensible passwd[/shadow?] db support

[Arvid E. Picciani]

On Mon, 13 Aug 2012 09:50:48 -0400, Rich Felker wrote:

> Well that's up to the Austin Group, not you. We implement POSIX.

fair enough. Now that i think of it, pulling out getpwent might not
be such a smart idea after all, considered that projects would need
musl specific build instructions then.


> Making /bin/ls depend on dynamic loading modules is a bit
> disgusting...

huh? yeah exactly my point. Why does /bin/ls load the passwd stuff in 
the first place?
It really shouldn't be in libc :/

-- 
Arvid E. Picciani

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Mon, Aug 13, 2012 at 09:22:07PM +0200, Arvid E. Picciani wrote:
> On Mon, 13 Aug 2012 09:50:48 -0400, Rich Felker wrote:
> 
> >Well that's up to the Austin Group, not you. We implement POSIX.
> 
> fair enough. Now that i think of it, pulling out getpwent might not
> be such a smart idea after all, considered that projects would need
> musl specific build instructions then.

Indeed.

Of course, one possible course of action would be not to support
anything but flat files like we do now, and require a library
replacing getpw* that admins would have to link to get other lookup
methods. But I think it we can do it in ~50 lines of clean code inside
libc, that's a lot better (and it avoids the issue of having to worry
about whether the static binary you're passing around supports
different lookup methods).

> >Making /bin/ls depend on dynamic loading modules is a bit
> >disgusting...
> 
> huh? yeah exactly my point. Why does /bin/ls load the passwd stuff
> in the first place?
> It really shouldn't be in libc :/

It reads it because ls -l prints the owners of files, and seeing a
username rather than a number is a lot more informative. Being able to
identify the owner of files by name rather than just as a number seems
like an important core system functionality to me...

Rich

Re: Design for extensible passwd[/shadow?] db support

[Arvid E. Picciani]

On Mon, 13 Aug 2012 15:28:33 -0400, Rich Felker wrote:

> It reads it because ls -l prints the owners of files, and seeing a
> username rather than a number is a lot more informative.

Oh yeah. Now it would be really horrible to have it build up an ldap
connection each time you do "ls". People do that in tight loops in 
scripts
and expect it to have semi-guaranteed runtime properties.

Can we at least have compile-time modules for this, so a 
system-designer
can choose between different implementations? Maybe then having ldab in 
there
directly isn't so bad at all. Hidding away the ldap problems in another
daemon sounds like an attempt to make a one-size-fits-all.



-- 
Arvid E. Picciani

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Mon, Aug 13, 2012 at 09:38:57PM +0200, Arvid E. Picciani wrote:
> On Mon, 13 Aug 2012 15:28:33 -0400, Rich Felker wrote:
> 
> >It reads it because ls -l prints the owners of files, and seeing a
> >username rather than a number is a lot more informative.
> 
> Oh yeah. Now it would be really horrible to have it build up an ldap
> connection each time you do "ls". People do that in tight loops in
> scripts
> and expect it to have semi-guaranteed runtime properties.

It only does the lookup with -l, and good implementations of ls will
cache the last user lookup (or maybe the last N for some large value
of N) to avoid being slow. Keep in mind, even without any remote
query, getpwuid_r has to parse the entire /etc/passwd file every time
it's called, which is not fast, so apps have a good reason to be doing
caching already.

glibc has a solution for this problem in the form of nscd, one of the
other solutions I proposed. It's a daemon whose purpose was just to
cache lookup results, but since the lookups are performed in the
daemon rather than the client, it could also be used as a translating
proxy to add support for arbitrary backends/protocols.

I have no idea how ugly the nscd protocol is, but if it's clean, I
think we could simply adopt it. musl-native systems would of course
need a new nscd (since the original one is part of glibc and depends
on the libnss mess) but musl binaries running on glibc systems could
even use the existing host nscd. Anyway, to determine if this solution
makes sense, somebody needs to do a bit of research into the nscd
protocol and how bad it is...

> Can we at least have compile-time modules for this, so a
> system-designer
> can choose between different implementations? Maybe then having ldab
> in there
> directly isn't so bad at all. Hidding away the ldap problems in another
> daemon sounds like an attempt to make a one-size-fits-all.

The problem with this is when you copy or static-linked busybox onto a
system that needs non-flat-file user lookups, and it fails to work
right...

I'm actually interesting in making _some_ features in musl
compile-time switchable, but only when they have a large size impact
that would affect really tiny embedded usage. The only examples that
come to mind so far are iconv charsets and crypt hashes. And in this
case, the option would not be to remove the interfaces entirely, only
to remove support for unneeded charsets (in the case of iconv) or
unneeded hashes (in the case of crypt).

I don't think removing ~50 lines of passwd entry lookup code would be
of much benefit for cutting down size, whereas every switch is an
addtional complexity cost (e.g. for cases that must be tested).

Rich

Re: Design for extensible passwd[/shadow?] db support

[Arvid E. Picciani]

On Mon, 13 Aug 2012 15:50:32 -0400, Rich Felker wrote:

> [..] parse the entire /etc/passwd file every time it's called

hm yeah. This stuff is all fairly ugly, which is why i hoped to get it 
out
of libc into a high level construct that can be replaced with system
specific parts.


> glibc has a solution for this problem in the form of nscd

The libc daemon from hell :/
A proxy daemon requires much more care and policy.
What happens when it times out, or responses are invalid, how do i
do balancing, ... "Falling back on local database" isn't graceful
degradation. It requires that you anticipate the situation and
make sure there is a fallback user in the passwd for maintenance.
Then security is a whole new topic. Who can access the daemon, what is
the retry policy, how do i handle linux namespaces, and containers...
So many things to deal with...


> The problem with this is when you copy or static-linked busybox onto 
> a
> system that needs non-flat-file user lookups, and it fails to work
> right...

Yes. They're incompatible. I don't see why this is a problem,
but then again i don't work on desktop systems at all.
They're not interesting systems, because resources are so inexpensive.


> I don't think removing ~50 lines of passwd entry lookup code would be
> of much benefit for cutting down size,

no, not at all. But being able to ignore ancient posix and go for
something that gets us to the product faster is something pretty 
valuable
for me. Let's take the fairly visible example of musl-android:
it doesn't have /etc/passwd, so i already have to downstream patch 
musl.
A proxy does not help me, because the fallback is still on /etc/passwd.

Again, i can only emphasize that these things are so fundamentally 
setup
dependent, that i think putting this in libc was a bad choice back 
then.



-- 
Arvid E. Picciani

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Mon, Aug 13, 2012 at 10:14:00PM +0200, Arvid E. Picciani wrote:
> >glibc has a solution for this problem in the form of nscd
> 
> The libc daemon from hell :/
> A proxy daemon requires much more care and policy.

A proxy daemon factors policy out of libc (where it doesn't belong) to
an isolated component that can be replaced or reconfigured without
breaking any apps (whether they're static or dynamic linked).

> What happens when it times out, or responses are invalid, how do i
> do balancing, ... "Falling back on local database" isn't graceful
> degradation.

These are all issues for implementing the proxy daemon, not for libc
to care about. Since it's a local daemon we're talking about, invalid
responses indicate you've been rooted and timing out indicates your
system has major problems (probably DoS).

> It requires that you anticipate the situation and
> make sure there is a fallback user in the passwd for maintenance.

Normally root is in the local passwd database anyway; it's the actual
_users_ whose identities are shared across networks.

> Then security is a whole new topic. Who can access the daemon, what is
> the retry policy,

All of that is at the daemon level; it's not relevant to libc.

> how do i handle linux namespaces, and containers...
> So many things to deal with...

That's a matter for people setting up these things to deal with.

> >I don't think removing ~50 lines of passwd entry lookup code would be
> >of much benefit for cutting down size,
> 
> no, not at all. But being able to ignore ancient posix and go for
> something that gets us to the product faster is something pretty
> valuable
> for me. Let's take the fairly visible example of musl-android:
> it doesn't have /etc/passwd, so i already have to downstream patch
> musl.
> A proxy does not help me, because the fallback is still on /etc/passwd.

Why does it hurt to attempt reading /etc/passwd if the file doesn't
exist and isn't used?

Rich

Re: Design for extensible passwd[/shadow?] db support

[Luca Barbato]

On 08/13/2012 09:50 PM, Rich Felker wrote:
> I have no idea how ugly the nscd protocol is, but if it's clean, I

Seems quite simple, albeit the marshalling of the structs you want to
pass around.

> think we could simply adopt it. musl-native systems would of course
> need a new nscd (since the original one is part of glibc and depends
> on the libnss mess) but musl binaries running on glibc systems could
> even use the existing host nscd. Anyway, to determine if this solution
> makes sense, somebody needs to do a bit of research into the nscd
> protocol and how bad it is...

I had a quick look at two implementations

https://github.com/freebsd/freebsd-head/tree/master/usr.sbin/nscd

http://repo.or.cz/w/glibc.git/tree/HEAD:/nscd

The bsd one seems vaguely simpler due the fact it doesn't have strage
macros generating functions and a large number of __fun/fun intermixed.

If I read http://repo.or.cz/w/glibc.git/blob/HEAD:/nscd/nscd-client.h

correctly the glibc one has a versioned header for its messages and some
structure while the bsd one seems more freeform with a
key:value:cache-policy approach.

The bsd uses kqueue and some state structure with function pointers
being replaced depending on the size of the request/reply, glibc one
uses poll and iovec.

So apparently musl might be compatible with glibc or break its
compatibility by using a different version number or looking for a
different socket file.

lu

Re: Design for extensible passwd[/shadow?] db support

[idunham]

> Presumably at some point, musl will be used in environments where it's
> not feasible to have the entire user database in a flat password file.
> Despite NIS being hideous, largish institutions use it for this
> reason; presumably LDAP is a much better option, and there may be
> other options still I'm not aware of.

Out of curiosity, is PAM excluded from consideration? Does it require a
dynamically-loaded library?
And will the pam-lite source ever show up somewhere? ;)

> What I'm looking for is a way to allow musl to access user data that's
> not provided with flat files in /etc, but without bloating musl or
> introducing dependencies on abominations like RPC.
>
> The idea I have is to add a single lookup method to musl, whereby it
> can query a local daemon of some sort for user information in a clean,
> simple protocol. Such a daemon can in turn translate to NIS, if
> desired, or to SQL db queries, or to whatever back-end the admin wants
> to use. I'm fairly settled on this general approach, but since I'm not
> at all familiar with the existing approaches, I'd like to seek some
> further input.
>
> The first main question is what protocol to use. One really simple
> choice would be a plain text protocol where the name/uid of requested
> user is sent over a socket (probably a datagram unix socket) and the
> response comes back in standard colon-delimited passwd format for the
> existing passwd code to parse. This seems very clean, but as far as I
> know it doesn't have any existing implementations.

I presume, for security reasons, that this would be the contents of
/etc/passwd as found on shadow-enabled systems...but how does the password
get authenticated?
Or are unix sockets immune to sniffing?

> Alternatively, we could make musl speak an existing query language
> (e.g. LDAP) directly, such that it could interface with any existing
> server out there that speaks the chosen protocol, or with a proxy that
> translates to other protocols like NIS.

If you do any sort of communication over sockets/networks/... with a
daemon, I'd suggest having musl communicate with a PAM-capable daemon.
PAM is meant for scenarios like this.

Isaac Dunham

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Sun, Aug 12, 2012 at 08:26:24PM -0400, idunham@lavabit.com wrote:
> > Presumably at some point, musl will be used in environments where it's
> > not feasible to have the entire user database in a flat password file.
> > Despite NIS being hideous, largish institutions use it for this
> > reason; presumably LDAP is a much better option, and there may be
> > other options still I'm not aware of.
> 
> Out of curiosity, is PAM excluded from consideration? Does it require a
> dynamically-loaded library?

PAM is not an implementation of the user database. It's for
authenticating logins. Completely different problem domain.

> > The first main question is what protocol to use. One really simple
> > choice would be a plain text protocol where the name/uid of requested
> > user is sent over a socket (probably a datagram unix socket) and the
> > response comes back in standard colon-delimited passwd format for the
> > existing passwd code to parse. This seems very clean, but as far as I
> > know it doesn't have any existing implementations.
> 
> I presume, for security reasons, that this would be the contents of
> /etc/passwd as found on shadow-enabled systems...but how does the password
> get authenticated?
> Or are unix sockets immune to sniffing?

Yes, they're immune to sniffing. The decision to use shadow or not is
independent of the decision on how to acess the user database.

> > Alternatively, we could make musl speak an existing query language
> > (e.g. LDAP) directly, such that it could interface with any existing
> > server out there that speaks the chosen protocol, or with a proxy that
> > translates to other protocols like NIS.
> 
> If you do any sort of communication over sockets/networks/... with a
> daemon, I'd suggest having musl communicate with a PAM-capable daemon.
> PAM is meant for scenarios like this.

No, PAM is made for logging in. Not telling which user has which uid
and what their realnames, home directories, or preferred shells are..

Rich

Re: Design for extensible passwd[/shadow?] db support

[Daniel Cegiełka]

2012/8/13 Rich Felker <dalias@aerifal.cx>:
> On Sun, Aug 12, 2012 at 08:26:24PM -0400, idunham@lavabit.com wrote:
>> Out of curiosity, is PAM excluded from consideration? Does it require a
>> dynamically-loaded library?
>
> PAM is not an implementation of the user database. It's for
> authenticating logins. Completely different problem domain.


A bit off topic: Is the traditional PAM/shadow will be supported in
musl? I would like to use full PAM/shadow/tcb stack from the Owl
with musl (+owl's pam modules). If not, what would be an alternative proposal?

best regards,
Daniel

>
> Rich

Re: Design for extensible passwd[/shadow?] db support

[Rich Felker]

On Mon, Aug 13, 2012 at 12:45:50PM +0200, Daniel Cegiełka wrote:
> 2012/8/13 Rich Felker <dalias@aerifal.cx>:
> > On Sun, Aug 12, 2012 at 08:26:24PM -0400, idunham@lavabit.com wrote:
> >> Out of curiosity, is PAM excluded from consideration? Does it require a
> >> dynamically-loaded library?
> >
> > PAM is not an implementation of the user database. It's for
> > authenticating logins. Completely different problem domain.
> 
> A bit off topic: Is the traditional PAM/shadow will be supported in
> musl? I would like to use full PAM/shadow/tcb stack from the Owl
> with musl (+owl's pam modules). If not, what would be an alternative proposal?

It's intended that these libraries work on musl, but I'm not aware of
whether they do yet or not. I think tcb wants the gensalt stuff in
libc, so that probably won't work without some patching.

Rich