You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
with a new chroot, sudo-rs is doing some unexpected thing.
$ /root/.cargo/bin/sudo --version
sudo-rs 0.2.1
$ /root/.cargo/bin/sudo ls
sudo-rs: cannot execute '/usr/bin/ls': No such device (os error 19)
create a chroot
cargo install sudo-rs
Create a sudoer file
/root/.cargo/bin/sudo ls
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults env_keep+="DEB_* BUILD* PATH OTHERMIRROR EXTRAPACKAGES"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
The text was updated successfully, but these errors were encountered:
After some digging, this seems related to the use_pty behaviour, which is the default for sudo-rs.
If you put Defaults !use_pty in /etc/sudoers (in the chroot), sudo-rs does work as you expect. On the other hand, if you use Defaults use_pty, you get the same problem with original sudo (although a slightly better error message):
# sudo ls
sudo: unable to allocate pty: No such device
I.e. this seems not really a bug but more an issue of the chroot environment being too limited for both sudo and sudo-rs to safely perform their intended function.
Specifically it appears that /dev/ptmx is not the proper pseudo terminal multiplexer device that it is supposed to be when using debootstrap, it might be a bug in the way debootstrap sets up the chroot.
with a new chroot, sudo-rs is doing some unexpected thing.
The text was updated successfully, but these errors were encountered: