Closed williamdes closed 2 months ago
Invalid option: Ok("\u{1b}")
Invalid option: Ok("\n")
While copying blocks of https://gist.github.com/alitoufighi/679304d9585304075ba1ad93f80cce0e Copying this text
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
# Host alias specification
# User alias specification
zabbix ALL=NOPASSWD: /mnt/storage/infrastructure/wdes-recovery-actions.sh *
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
includedir /etc/sudoers.d
Complains about \n It would be nice to know on what line at what position and it looks like some Rust is Printed "Ok()"
Does this behaviour only happen when you try to remove the final line? sudo complaining about a \n
can be due to my insistence that a /etc/sudoers
that does not end in a newline is a reason for a diagnostic. But I imagine visudo already makes sure that there is a final newline when copying the temporary file.
- @squell: It is a parsing issue, what do you think about adding span info so those errors can be reported?
Most early parse errors (which this feels like it is) should have positional info already; IIRC the only exception are semantic errors. But I haven't tried to reproduce this issue yet.
So I think the original issue is simply a question of "we forgot the truncate the file". I'm fine with not splitting this issue and adding positional info to visudo
error messages as part of this PR. That should simply be an issue of not ignoring the position info in the crate::sudoers::Error
type.
Thank you for taking care of this issue. I am not really sure what it was exactly since it was a non sense battle to get my edits. The other visudo works fine
Describe the bug
While I edit visudo and try to remove a commented line the line will be back
To Reproduce
I have this visudo content:
And I am trying to remove
#rt
that was in factzabbix ALL=NOPASSWD: /mnt/storage/infrastructure/wdes-recovery-actions.sh restart
that I had replaced by*
and for some reason it did not. I then hadAnd I am now fighting to remove this text that keeps coming back
I am using nano, but tried with vi too.
Expected behavior A clear and concise description of what you expected to happen.
Environment (please complete the following information):
sudo-rs
commit hash: 0.2.2 (Debian packaging)