I told someone to "chmod sudoers", then she couldn't change it back. Is this a bug?
 

The story is simple. Someone asked me how to let another user to use "sudo". I told her to edit /etc/sudoers. Since I am an "Emacs" guy and not familiar with vi and visudo, so the fatal step is that I told her to:
Then she couldn't change it back, because nobody could use "sudo" anymore. She is not the root user and didn't have the password of root. I googled, and learned that the solution is to reboot the system to "recovery mode" and change it back. She couldn't reboot it because some important codes are running in the background.

I have never thought that Linux has been so fragile: a little mistake by a normal user could make such a big problem! I think this is a bug!

Feel free to give your comments, thanks!

No, this is not a bug, no, this wasn't done as normal user. When using sudo you effectively are root, so you have to be as careful as when you would directly have logged in as root.
By the way, to use a different editor with visudo you have nothing more to do than set your EDITOR environment variable. You can do that temporarily with using a construct likeAlso, there is a reason why visudo exists, namely because it checks the file for errors before it writes it to the disk. So it is never a good idea to use an editor to edit that file instead of visudo.
The real question that remains is why don't you simply have used instead of chmoding the file?

Anyways, unless the person you advised to do that has a root shell open, gets the root password or is able to reboot the machine there is no way to fix that.

Thank you for your reply, Tobi.

I admit that what I instructed her was a mistake. But the stupid thing is that:
1. sudo can do a change.
2. sudo can't change it back.
So I consider it as a bug.

And by the way, in my salckware, will open it in read-only mode. I can't edit it. I am not sure about Ubuntu.

Your tip about "EDITOR=emacs" might be useful. And your these sentences really make sense:

You can edit files as root from within a running emacs with According to this askubuntu thread, pkexec can also work (if it's installed).

It is not. It is a security feature. sudo is programmed in a way that the sudoers file has to have 0440 for access rights. If this is changed the sudo program considers the sudoers file as being compromised and refuses to give anyone root access. This is a good thing, as long as sudo is used in the way it is being intended.

This method works for a root-owned file, but not for a 0440 file.

Thank you, anyway.

I think linux should be very tough.
It should forbid non-root users to touch the file /etc/sudoers.

It does. But you have told that user to use sudo, which makes her root. So the file was not altered by a non-root user.

Emacs opens the file in read-only mode but you can make the buffer editable with C-x C-q

Just in case this may help, here is the method to fix the sudoers file from recovery mode:
http://psychocats.net/ubuntu/fixsudo
Note that in my experience from reading threads here on LQ, one of the best ways to break an Ubuntu system is to enable the root account, and or to mess with the /etc/sudoers file.
I have used every version of Ubuntu since the inaugural 4.10. I have never enabled the root account on Ubuntu because I have never found any valid reason for doing it.
I also never mess with the /etc/sudoers file.
I also never have these problems.

You can elevate users to use sudo from the user accounts GUI on Ubuntu.

Thank you, ntubski!

Thank you, tommcd!
You are right, one should not mess with the /etc/sudoers file.

She can "sudo", but can't "su", which makes her a half-root user. A mistake I instructed her made a huge problem: no one can use sudo anymore. Maybe she is not a non-root user, but she isn't a root user too.

By the way, today I rebooted the system, and got into "recovery mode". Without the root password I can log in as root! Is this safe? It's convenient though.

New question: What should I do if I made the same mistake on a system without a "Recovery Mode"? (If I didn't have the root password either.) By now all I can think of is to boot the machine with another linux system (using a live CD or a thumb-drive). Will it work? Or are there any better ways?

it's only unsafe if the attacker is sitting in front of the machine, physical access trumps any and all security you place on a machine anyways, so don't sweat it.. yes you can set a grub password but that is only a relatively minor deterrent to a determined attacker who has stolen your machine.

ALL Linux machines have a recovery mode, whether or not it was conveniently placed in the grub menu or not is the only difference.
it's called single user mode and can be accessed by manually (temporarily) appending the word 'Single' to the end of the kernel line of the grub entry at boot, or worst comes to worst adding
instead of single then at the prompt typing
or if that doesn't even work, boot to live media
replacing sda1 with your root volume
this creates an environment in which you have root control over your installed system, and if it works, can fix a non bootable system as a last resort to having to re-install

the above methods are exactly why physical access trumps any security
so again, in answer to your query, there is always a recovery mode of some nature available on any Linux system, even if it isn't conveniently stuck in the boot menu for you.

even modern macs, which are a bsd userspace on a mach microkernel has single user mode, not sure if they have chroot but that's off topic.

If sudo is set up the way it is on Ubuntu systems (without restrictions which programs a user in the sudo group can run) than the user is in fact a full root user, only without access to the root account. There is no difference at all if you run a program with sudo or from a root account.

sudo elevates privileges and uses the person's own password, su switches users and uses the root account, if enabled, unlike ubuntu and mac os X but i second tobi, with sudo set the way the 'buntu systems configure it by default, she IS a full root user since sudo was configured to allow all access.