Re: Credcheck- credcheck.max_auth_failure
On 2024-12-16 10:37:59 -0500, Ron Johnson wrote: > On Mon, Dec 16, 2024 at 10:19 AM Peter J. Holzer wrote: > > On 2024-12-16 09:17:25 -0500, Ron Johnson wrote: > > Local (socket-based) connections are typically peer-authenticated > > (meaning that authentication is handled by Linux pam). > ^^^ > Is it? I haven't checked the source code, but this doesn't seem > plausible. You can get the uid of a socket peer directly from the > kernel, which can be converted to a user name via getpwuid, and the > mapping to postgresql roles is done via pg_ident.conf. I see no role for > PAM in that path. > > > https://www.postgresql.org/docs/16/auth-peer.html > > " > The peer authentication method works by obtaining the client's operating > system > user name from the kernel and using it as the allowed database user name (with > optional user name mapping). This method is only supported on local > connections. > [snip] > Peer authentication is only available on operating systems providing the > getpeereid() function, the SO_PEERCRED socket parameter, or similar > mechanisms. > Currently that includes Linux, most flavors of BSD including macOS, and > Solaris > . > " > > That means pam No, it doesn't. PAM is used to authenticate a user to the OS (plus to do a bit of setup and teardown at the beginning and end of each session). But here the user is already authenticated to the OS and postgresql is using that information to authenticate the user to itself. This will use the nsswitch mechanism on Linux (and probably something similar on the other OSs) to do the uid->username lookup, but it will not use PAM, since that simply isn't what PAM is for (or capable of to my knowledge). hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature
Re: Credcheck- credcheck.max_auth_failure
On Tue, Dec 17, 2024 at 1:39 PM Peter J. Holzer wrote: > On 2024-12-16 10:37:59 -0500, Ron Johnson wrote: > > On Mon, Dec 16, 2024 at 10:19 AM Peter J. Holzer > wrote: > > > > On 2024-12-16 09:17:25 -0500, Ron Johnson wrote: > > > Local (socket-based) connections are typically peer-authenticated > > > (meaning that authentication is handled by Linux pam). > > ^^^ > > Is it? I haven't checked the source code, but this doesn't seem > > plausible. You can get the uid of a socket peer directly from the > > kernel, which can be converted to a user name via getpwuid, and the > > mapping to postgresql roles is done via pg_ident.conf. I see no role > for > > PAM in that path. > > > > > > https://www.postgresql.org/docs/16/auth-peer.html > > > > " > > The peer authentication method works by obtaining the client's operating > system > > user name from the kernel and using it as the allowed database user name > (with > > optional user name mapping). This method is only supported on local > > connections. > > [snip] > > Peer authentication is only available on operating systems providing the > > getpeereid() function, the SO_PEERCRED socket parameter, or similar > mechanisms. > > Currently that includes Linux, most flavors of BSD including macOS, > and Solaris > > . > > " > > > > That means pam > > No, it doesn't. PAM is used to authenticate a user to the OS (plus to do > a bit of setup and teardown at the beginning and end of each session). > But here the user is already authenticated to the OS and postgresql is > using that information to authenticate the user to itself. This will use > the nsswitch mechanism on Linux (and probably something similar on the > other OSs) to do the uid->username lookup, but it will not use PAM, > since that simply isn't what PAM is for (or capable of to my knowledge). > pam is _indirectly_ used, since like you said, that's what authenticates the OS user that "peer" authentication needs. -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster!
Re: Disabling vacuum truncate for autovacuum
On Tue 2024-12-17 08:30:19 +0100, Laurenz Albe wrote: > > Would I need to disable the settings on catalog tables too? (To rule out > > any possibility of it happening). Are there any other things I might be > > missing? > > Potentially yes. But unless you are using temporary tables or create, > alter and drop lots of objects, that shouldn't be necessary. I see. That makes sense. I do have some things that use temporary tables as well as some jobs that create/drop objects. They are not very frequent nor are there a huge number objects involved, but I suppose it could still be an issue. I'm not keen on altering the catalogs, but it sounds like if I want to be very safe then I would need to. > > I am also wondering if having an autovacuum setting to control it would be > > a good idea for a feature. > > I'm all for that. I previously had old_snapshot_threshold enabled, which would have done this anyway I believe, including for the catalog tables. That was convenient! > Yours, > Laurenz Albe Thank you Laurenz! I've read a bunch of your writing and I've learned a lot from you. I'm a big fan :-). Thank you for what you do!
