/usr/bin/passwd suid

[Petar Bogdanovic]

Hi again,

after upgrading from 6.0.5_PATCH to 6.0.6_PATCH, I got this:

Setuid deletions:
-r-sr-xr-x 2 root wheel 31003 Aug 27 15:13:03 2014 /usr/bin/passwd
-r-sr-xr-x 2 root wheel 31003 Aug 27 15:13:03 2014 /usr/bin/yppasswd

and indeed:

$ ls -la /usr/bin/passwd
-r-xr-xr-x 3 root wheel 31003 Oct 7 16:21 /usr/bin/passwd

This happened before:

not sure what happened here but after the upgrade from 6.0.1_PATCH to
6.0.2 the daily insecurity mail reported the following:

Checking setuid files and devices:
Setuid additions:
-r-sr-xr-x 2 root wheel 31003 Jun 3 12:21:03 2013 /usr/bin/passwd
-r-sr-xr-x 2 root wheel 31003 Jun 3 12:21:03 2013 /usr/bin/yppasswd

https://mail-index.netbsd.org/netbsd-users/2013/06/04/msg012933.html

My upgrade procedure is simple and always the same..


Thanks for any ideas or pointers,

Petar

[Martin Husemann]

Post by Petar Bogdanovic
My upgrade procedure is simple and always the same..

Does it include manually extracting the sets? Maybe you did something
like:

tar xfz base.tgz

but you need to add "p", i.e.:

tar xpfz base.tgz

to (p)reserve the permissions. You can fix this by re-extracting the sets,
or by using mtree(8) and the data in /etc/mtree (not tested, something like:
cat /etc/mtree/* | mtree -U)

Martin

[Petar Bogdanovic]

Post by Martin Husemann
tar xpfz base.tgz
to (p)reserve the permissions. You can fix this by re-extracting the sets,
cat /etc/mtree/* | mtree -U)

When upgrading, I'm always using contents from my HISTFILE and that
had a (p) in its tar xpzf since the first time I issued the command.

On the other hand, lets say I didn't use (p), there would probably be a
lot more files without the suid bit set. So why is it always limited to
/usr/bin/passwd and /usr/bin/yppasswd?

Fixing this is not a problem but I wonder why it happens every once in a
while.