| 1 |
On Wed, Sep 2, 2020 at 10:01 AM Walter Dnes <waltdnes@××××××××.org> wrote: |
| 2 |
> |
| 3 |
> The deciding factor for me is that elogind pulls in PAM. PAM is to |
| 4 |
> me what HAL is to Dale. Basically "everything you know is wrong". PAM |
| 5 |
> imposes its own config files, and anything you read on man pages for a |
| 6 |
> service may not apply when PAM controls access to that service. |
| 7 |
|
| 8 |
PAM is the reason that on my single-user server I can require a OTP to |
| 9 |
log in via ssh, but not via POP3. Back when I was using it to run |
| 10 |
samba for multiple remote users I could enable login to samba, but |
| 11 |
nothing else, that way I didn't have to worry about somebody picking a |
| 12 |
dumb windows password making my server open to log in via ssh or some |
| 13 |
other service from anywhere in the world. |
| 14 |
|
| 15 |
Most of this stuff is designed to make stuff more configurable. It is |
| 16 |
true that it changes where you configure things. However, once you |
| 17 |
learn how PAM works you can use a single syntax to control how |
| 18 |
authorization works for every daemon on your system, and have all your |
| 19 |
access policies in once place. This is instead of having per-daemon |
| 20 |
config files with their own rules. |
| 21 |
|
| 22 |
Certainly multi-user systems like corporate desktops is one |
| 23 |
application for this stuff, but it is hardly the only one. And the |
| 24 |
defaults generally work fine so you don't really need to mess with |
| 25 |
things unless you feel the need to. |
| 26 |
|
| 27 |
I get that in the good old days everybody just edited /etc/rc or |
| 28 |
whatever to configure their system, but most of the complexity exists |
| 29 |
for a reason. In some cases you can avoid it, but upstream projects |
| 30 |
are becoming increasingly unwilling to tolerate the 0.01% who don't |
| 31 |
want to just use the distro defaults. |
| 32 |
|
| 33 |
-- |
| 34 |
Rich |
Archives