User Details
- User Since
- May 10 2014, 4:26 AM (419 w, 10 h)
Today
Yesterday
Interestingly, {0,1,3}.{freebsd,fedora,debian,ubuntu}.pool.ntp.org support only IPv4. While 2.{freebsd,fedora,debian,ubuntu}.pool.ntp.org all support IPv4 and IPv6.
Thu, May 19
Wed, May 18
Sun, May 15
Sat, May 14
Thu, May 12
Wed, May 11
Mon, May 9
Mon, May 2
What Linux did was a hack. (Remember PAM was written by Sun Microsysystems 20, 25 years ago). Short of changing the spec or adding some kind of kernel interface the linux-pam maintainer implemented a hack.
Why is this surprising? /etc/master.passwd is 0600 (or we repeat the mistakes of the 1980's and 1990's again). pam_unix.so is loaded into and runs in the process's own address space under the UID of the user, a user who must not have read access to /etc/master.passwd (FreeBSD) or /etc/shadow (Linux, Solaris).
The other option might be to create a port that would provide an alternate pam_unix.so with an accompanying daemon. Or possibly add a linux-pam port. Either option is ugly and not recommended either.
Fri, Apr 29
Wed, Apr 27
Mon, Apr 25
Fri, Apr 22
Apr 17 2022
Apr 16 2022
Apr 14 2022
Apr 13 2022
Apr 10 2022
Apr 8 2022
Apr 7 2022
Apr 5 2022
Apr 4 2022
Apr 1 2022
The case construct is probably the most elegant solution.
Further to my previous comment, I'm thinking:
I see that.
Mar 31 2022
My mistake. The randomness issue was fixed a while ago.
Mar 30 2022
Agreed. I commented, before, that a rate limit that is adjusted by a 16 bit value was a regression. Reducing the randomness from 32 to the original 16 bits will duplicate the same mistake WPA made with WPS. This change would allow any attacker to guess the port number more easily. @rpokala expressed it better than I did. I would be OK with this if the random adjustment remained a 32 bit value.