On Fri 31 Mar 2023 09:41:16 +0200, Marc Haber wrote:
> Please add your reasons to this bug, so that the sudo maintainers can
> properly consider the reasons in their decision.
I personally DON'T need sudo-ldap anymore.
1. I ran sudo-ldap + slapd on an Ubuntu 10.04 farm until 2022.
It was mainly for things like "sudo eject" (back when blank CDs were
expensive, and HAL was still a thing) and
"sudo ldapadduser" (to let managers onboard staff & create mailing lists
without sysadmin help).
I was planning to replace it with a "pure" samba AD stack, but the
Windows-iness just got Too Hard, so
I ended up going back to plain /etc/shadow and /etc/sudoers.d, now managed
by ansible.
2. I set up sssd in 2022 at another site, on SLES 12, aimed at a Windows AD
stack.
I wasn't allowed to use sssd for sudo, though, so that site is still using
sudoers.d (also via ansible).
It wasn't clear if sssd-sudo required me to add additional schemata to AD,
like sudoers-ldap does.
If NOT, that would definitely be an advantage for sssd-ldap over sudo-ldap
:-)
3. I run de Jong's libnss-ldapd / libpam-ldapd at another site, and it works
well there, but again,
the sudo rules are simple enough they get hard-coded into sudoers.d.
I like https://manpages.debian.org/slapo-ppolicy.
4. For automated machine-to-machine jobs (e.g. zfs send/receive) I prefer to
skip sudo altogether.
For example, I now use https://manpages.debian.org/zfs-allow to let a
non-root system user
"zfs-receive-trinity" have permission to mess with ZFS dataset
"morpheus/srv/backup/trinity".
I've been thinking about https://archive.org/details/lca2020-Zero_Trust_SSH
but
right now I'm still just using Ed25519 keypairs for everything.
5. One thing I do really appreciate is that the sudoers.ldap objects
are MUCH easier to understand than an equivalent sudoers.d config file.
dn: cn=responsible,ou=groups,o=cyber
objectClass: posixGroup
description: Staff responsible for OUR systems and networks.
description: I often reflect that if "privileges" had been called
"responsibilities" or "duties", I would have saved thousands of hours
explaining to people why they were only gonna get them over my dead body. --
Lee K. Gleason, VMS sysadmin
gidNumber: 2049
memberUID: twb
memberUID: REDACTED
dn: cn=defaults,ou=sudoers,o=cyber
objectClass: sudoRole
sudoOption: always_set_home
sudoOption: env_reset
sudoOption: ignore_dot
sudoOption: ignore_local_sudoers
sudoOption: insults
sudoOption: !setenv
sudoOption: set_logname
dn: cn=%responsible,ou=sudoers,o=cyber
objectClass: sudoRole
sudoUser: %responsible
sudoHost: ALL
sudoRunAsUser: ALL
sudoRunAsGroup: ALL
sudoCommand: ALL
sudoOption: !authenticate
dn: cn=bbq,ou=sudoers,o=cyber
description: Staff need this to burn CDs and DVDs on BBQ.
objectClass: sudoRole
sudoUser: %cyber
sudoHost: bbq
sudoRunAsUser:
sudoRunAsGroup: cdrom
sudoCommand: /usr/bin/wodim
sudoCommand: /usr/bin/cdrecord
sudoOption: noexec
When I read an /etc/sudoers.d/ugh.conf I often start by reading
https://manpages.debian.org/sudoers.ldap just so I don't go mad.
If sudo could have the sudo-ldap format in flat file, I'd be happier.
At least in cases when I have more than "%sudo (ALL:ALL) NOPASSWD: ALL".
As an analogy, consider how much nicer it is now we can use
/etc/apt/sources.list.d/debian.sources (deb822 format)
instead of the old
/etc/apt/sources.list.d/debian.list(legacy format)
