[Pkg-shadow-devel] Re: [Pkg-shadow-commits] r298 - trunk/debian/patches

[Alexander Gattin]

Hi!

On Sat, Jun 25, 2005 at 12:35:32AM +0200, Nicolas François wrote:
> On Fri, Jun 24, 2005 at 02:25:42AM +0200, Nicolas François wrote:
> > We should also check what pwck does when passwd and shadow are not
> > consistent.
> 
> If /etc/passwd contains an entry which is not in /etc/shadow, no warning
> is issued.
> 
> I would prefer to have at least a warning in this case (when the system in
> shadow enabled).

I think what you propose is more correct behaviour.

> I will have the same question as for grpck: is it better to propose to remove
> this entry from /etc/passwd or to propose to add an entry to /etc/shadow?
> (Another option is to just warn the user, and let her add/remove the
> entry)

OK. When we discussed the issue on IRC, I desided the
way pwck works was "propagating passwd to shadow", i.e.
master-to-shadow mirroring.

This is policy aspect, I mean this takes one source of
data (passwd) as primary and considers other as
derived.

Technically this has some problems. In case of
passwd/shadow former has 7 fields while latter has 9.

So technically it's impossible to get all the data for
shadow from passwd, when there's an entry in latter
which is missing from the former. At least, while some
missing fields may have reasonable defaults, e.g.
sp_min, sp_max, sp_warn, sp_inact, others are hardly
re-creatable (sp_pwdp, sp_lstchg, sp_expire).

I think the clash of pwck's policy against technical
problems is the cause why pwck does nothing when
"/etc/passwd contains an entry which is not in
/etc/shadow". I.e. technical problems prevent pwck
from passwd->shadow mirroring while _both_ ;) policy
and technical problems prevent it from mirroring in
reverse direction.

But this cannot be an excuse to not issuing even a
warning here.

With grpck we should think the same way, i.e. take
/etc/group as primary source and operate according to
this principle until there's a technical problem.

The most interesting thing here is that /etc/gshadow
_usually_ does not contains anything besides what
is in /etc/group already. Or, from another point of
view there _are_ reasonable defaults for sg_passwd 
and sg_adm fields (empty ones).

So e.g. when we encounter an entry which is in
/etc/group and missing from /etc/gshadow we can
safely propose to add an entry to gshadow.

-- 
WBR,
xrgtn