UX: /etc/sudeoers.d/myrules.conf doesn't work - allow dots or help users along the way

Aperta
  • Qualcosa non va?
#486 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
c
Ambito
cli

Direzione di ricerca

Start by reading the sudoers manual section on files in sudoers.d, then trace how sudo selects and skips files in that directory; the issue does not name source files or tests. The report suggests several possible UX changes, including accepting .conf files, adding guidance, or warning interactively, so first identify the existing behavior and tests before assessing scope. Done means an agreed change helps users understand why a dotted file is ignored.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

In my experience the drop in directories like /etc/ssh/ssh_config.d/ for example need a .conf file extension to actually take effect. For sudo the contrary seems to be the case: The file is silently ignored if it contains a dot which of course is true for my file ending in .conf.

In an ideal world there would be a standard for stuff like that so that users like me wouldn't need to remember or figure it out as they are using a myriad of different tools. On the other hand I realize that changing that behavior now for sudo might be problematic for all the systems already depending on that behavior, as much as I'd like to see it unified. (But maybe allowing just .conf wouldn't be too bad? The Documentation just mentions that dotted files are skipped to avoid issues with package managers but I don't think any of them would be writing .conf files there...)

What else could be done to improve the UX?

  • Put a readme.txt or a example file in sudoers.d which educates about this circumstance, this is the first place I have looked but the directory was empty for me. (Fedora 43 after many upgrades.)
  • I've briefly looked into man sudoers but didn't really think about where to look specifically. Only later I found that the information is actually there hidden somewhere in the middle of of over 2000 lines. (A search engine and stackoverflow came to the rescue.)
  • I've tried sudo -v and looked into man sudo for a verbose mode (which is helpful in debugging ssh client issues) and also tried sudo -l but neither helped me figure out why my new .conf file was doing nothing.
  • At least when running interactively (like asking for a password) I don't see any harm in announcing that a dotted file in sudoers.d was skipped because of the dot.

Finally a big thank you to all the people creating and maintaining sudo! ❤️
(Apart from this minor annoyance in the config it never let me down 😉 )

In retrospect the title for this issue feels a bit clunky, feel free to edit or suggest improvements if you got better ideas.

Lingua principale
C
Stelle
1.7k
Fork
306
Merge medio
1g 8h
PR unite (30g)
24

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sudo-project/sudo

Tutte le issue di sudo-project/sudo

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.