meson: shadow passwords check is invalid on NetBSD

[rdmark]

From Hauke:

Meson complains about missing shadow password support on *BSDs, who
have had mandatory shadow passwords since 4.4BSD. The check should be
conditional for linux.

The build system reports

Has header "shadow.h" : NO 
meson.build:1743: WARNING: Shadow password support requested but required header not found
Checking for size of "off_t" : 8 

[rdmark]

The two symbols from shadow.h we use are the spwd data structure and getspnam() function.

As a side note, the have_shadow build system flag is unused. Should add a line for this in the summary.

Edit: The flag wasn't unused. It adds "shadow" to the list of auth methods.

[rdmark]

@hfath Do I understand it correctly that shadow passwords on *BSDs uses a different mechanism that requires no intervention in C code?

[hfath]

4.4BSD and all its descendants come with a built-in "shadow password" mechanism (in libc, IIRC). Unlike with Linuxen, it is not optional.

[hfath]

Hum - right now, any volume I mount on 4.0.7 @ NetBSD to the Mac is owned by root, 0700.

I'll have to take a closer look at what Netatalk does with shadow passwords, and how it changed recently.

[rdmark]

That's odd. Was the behavior in 4.0.6 different?

We changed practically no C code between 4.0.6 and 4.0.7, except for the bstrlib.c junk.

If there was a change, maybe it was triggered by the quota fix, which should be leading to new code paths on *BSDs.

[hfath]

I wonder... my 4.0.6 home server installation works with local auth (/etc/{,master.}passwd), the test server at work with NIS auth. Do you know offhand how netatalk accesses passwd information? I looked around but didn't get a clear picture.

On *BSD, getpwent(3) and friends go through /etc/nsswitch.conf for passwd information, and I guess the shadow code for Linuxen does something similar.

[hfath]

The pkgsrc 4.0.6 package works on the NISed machine. I'll have to dive into my package update...

[rdmark]

I wonder... my 4.0.6 home server installation works with local auth (/etc/{,master.}passwd), the test server at work with NIS auth. Do you know offhand how netatalk accesses passwd information? I looked around but didn't get a clear picture.

On *BSD, getpwent(3) and friends go through /etc/nsswitch.conf for passwd information, and I guess the shadow code for Linuxen does something similar.

I don't have any profound insights here beyond what I get from a naive reading of the respective UAM code in etc/uams/*_passwd.c

Are you testing with or without your additional build system patch in #1768 ?

[rdmark]

Hum - right now, any volume I mount on 4.0.7 @ NetBSD to the Mac is owned by root, 0700.

Just to understand the symptoms: permissions are expressed as 0700 on the volume after mounting on the Mac client side, which is different from the corresponding directory on the host NetBSD side?

[hfath]

No, the permissions and ownership matches the server-side information. Presumably, afpd(8) runs as root, but does not chown the files copied to the server filesystem to the user logged in.

I looked at my package modifications since 4.0.6 in the meantime, and they appear irrelevant.

[hfath]

That was with the proposed #1768 patch. I'll try rolling it back tomorrow.

[hfath]

Dropping the patch doesn't make a difference, and apart from that, the changes in the packaging configuration are nominal. Interesting quest...

[rdmark]

Does it help if you set the GID sticky bit on the shared volume root dir on the host, e.g. 2775 ?