Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#651042: token manipulation error for NIS

74 views
Skip to first unread message

Harald Dunkel

unread,
Dec 5, 2011, 4:40:02 AM12/5/11
to
Package: passwd
Version: 1:4.1.4.2+svn3283-2+squeeze1

If I try to change the password of my account in NIS,
then I get

% passwd
passwd: Authentication token manipulation error
passwd: password unchanged
%

Please note that it didn't even ask for the old
password. Using yppasswd there is no such problem.

The NIS Server (Lenny) merges passwd and shadow information.
MERGE_PASSWD=true


Regards

Harri



--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Nicolas François

unread,
Jan 8, 2012, 11:10:02 AM1/8/12
to
Hello,

On Mon, Dec 05, 2011 at 10:35:59AM +0100, harald...@aixigo.de wrote:
>
> If I try to change the password of my account in NIS,
> then I get
>
> % passwd
> passwd: Authentication token manipulation error
> passwd: password unchanged
> %
>
> Please note that it didn't even ask for the old
> password. Using yppasswd there is no such problem.
>
> The NIS Server (Lenny) merges passwd and shadow information.
> MERGE_PASSWD=true

I do not know NIS, but I do not think passwd should be used to change a
password when NIS is in use.

http://tldp.org/HOWTO/NIS-HOWTO/rpasswdd.html

Did passwd work in the past?
Do you know if passwd is intended to work in such case?

Best Regards,
--
Nekral

Harald Dunkel

unread,
Jan 9, 2012, 3:40:01 AM1/9/12
to
Hi Nicolas,

On 01/08/12 16:57, Nicolas François wrote:
>
> I do not know NIS, but I do not think passwd should be used to change a
> password when NIS is in use.
>

According to its own man page yppasswd(1) is deprecated.

> http://tldp.org/HOWTO/NIS-HOWTO/rpasswdd.html
>

I do not see how this is relevant on Squeeze. pwdutils are
not included in Squeeze or Sid.

> Did passwd work in the past?

For Squeeze I cannot say.

> Do you know if passwd is intended to work in such case?
>

I had expected passwd is based on pam, isn't it?


Regards

Harri

Nicolas François

unread,
Jan 9, 2012, 4:20:01 PM1/9/12
to
Hi,


On Mon, Jan 09, 2012 at 09:22:59AM +0100, harald...@aixigo.de wrote:
>
> On 01/08/12 16:57, Nicolas François wrote:
>
> > Do you know if passwd is intended to work in such case?
> >
>
> I had expected passwd is based on pam, isn't it?

OK. Right, if supported by PAM, then passwd should work.

Did you get anything in the system log files (/var/log/auth.log or
/var/log/syslog)?

Which PAM module do you use, with which options?

Can you enable auditing or debugging for this PAM module?

Best Regards,
--
Nekral

Alexander Gattin

unread,
Jan 10, 2012, 3:30:02 AM1/10/12
to
Hello,

On Mon, Jan 09, 2012 at 10:09:44PM +0100, Nicolas
François wrote:
> On Mon, Jan 09, 2012 at 09:22:59AM +0100,
> harald...@aixigo.de wrote:
> > I had expected passwd is based on pam, isn't it?
>
> OK. Right, if supported by PAM, then passwd
> should work.

IIRC passwd's operation for NIS auth works through
libc/nss' getspent(), but for changing auth tokens
it resorts to writing /etc/shadow directly, am I
correct here?

And as far as I can remember, changing NIS
passwords never worked in passwd...

--
With best regards,
xrgtn

Nicolas François

unread,
Jan 11, 2012, 5:40:01 PM1/11/12
to
On Wed, Jan 11, 2012 at 08:44:05AM +0100, harald...@aixigo.de wrote:
> Seems that I have to add an option "nis" to pam_unix.so to
> make it work (better). My common-passwd is now:

Nice to know this works with pam_unix (at least this is consistent with its
documentation (nis: NIS RPC is used for setting new passwords.).

If the option was not set before, then I'm not surprised by the behavior
(this is similar to pam_unix failing to get the authentication token from /etc/shadow)

> Looking at the NIServer I see that /etc/shadow is changed,
> even though NIS merges passwd and shadow into a single
> database. Seems OK to me.
>
> It is just weird that passwd asks for the NIS root password,
> if I try to change the local root password:
>
> # passwd
> Changing password for root.
> NIS server root password:
> Enter new UNIX password:
> Retype new UNIX password:
> passwd: password updated successfully
>
> It still accepts and changes the local root password, so
> this is not a big issue.

Those prompts are coming from the PAM module, not from passwd itself. SO
I guess they are doing the right thing, unless there are mis-configurations
from your side.

I've read you have to include/exclude some accounts with nis, putting
lines like
+miquels:::::::
-miquels:::::::

maybe you can also restrict the users which are exported by the server.

> Question: On Debian /etc/pam.d/common-passwd is generated
> using pam-auth-update and some templates in /usr/..., AFAICS.
> What is the _real_ place to add the "nis" (or other options)
> to pam_unix.so? Shouldn't it be set by default, if NIS is
> installed?

That might be worth being discussed with the nis maintainer. I do not
know nis enough to answer.
I would guess that the new PAM config handling mechanism could be used for
this.

I would propose to close this bug. Do you agree?

You may want to open a new bug for the handling of the PAM configuration
when NIS is installed/enabled on a system.

Harald Dunkel

unread,
Jan 12, 2012, 2:20:01 AM1/12/12
to
Closing this bug is fine with me.

Many thanx

Harri
0 new messages