关于对错误：sudo: /usr/bin/sudo必须属于用户ID0（的用户）并设置setuid位的错误的反思（ubuntu16.04）

发生原因和过程

过程如下：执行了chmod 777 /opt/work-namespace，
			是的仅仅是这个命令就让整个系统发生了天翻地覆的变化，这一切，只是因为数月之前的一个操作的失
		误。经过了大佬对蛛丝马迹的寻找总算是找到发生错误的原因，原来是因为数月之前的操作失误导致了
		把原来应该把一个分区挂载到/opt/work-namespace的，结果误把系统分区挂载到/opt/work-
		namespace了，所以，只是因为以上的chmod命令就导致了整个系统几乎废掉。就发生了如标题所示的错误。
		
			其实要恢复这个错误不难，但是如果这台机器你恰好把他用到了企业生产中，那么你将会非常的烦
		恼，你不可以让服务断掉；不可以让原来指定好的开发计划延迟；你也不能放弃你现在手头的任务。
		但是这个问题确实是你要处理的，如果这个服务器在外地，或者在云端，你怎么办？？
		
		这样的错误非常难以避免，毕竟我平时已经非常小心，如履薄冰。
		幸好，这台服务器还没有用于生产。那么我们应该如何解决这个问题，如何避免呢？？
		2种方式，如果你有重要的数据，请一定要先看第一种
		解决方式如下。

解决办法：

方法一:

1：在开始任何操作之前，一定要尽量把重要数据先弄出来，备份好。尽量去做，因为你有可能在恢复的过程中把系统直接搞没了就。
2：准备一个系统安装盘，修改主板配置的启动顺序，进入试用版的系统.进入root权限，记得不是修改试用版系统，而是修改原来的那个出问题的系统的权限。修改如下的权限：

chmod 4755 /usr/bin/sudo

chmod 4755 /bin/su

chmod 4755 /usr/lib/sudo/sudoers.so

chmod 4755 /etc/sudoers.d

chmod 4755 /etc/sudoers.d/01_always_set_sudoers_home

3：如果只改这些，可能还会因为sudoers的权限太高而发生如下错误：
sudo: /etc/sudoers is world writable
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

这个的修改方式如下：
chmod 555 /etc/sudoers

chmod 555 /etc/sudoers.d/README

然后重启即可进入原来的系统即可。


#############################################
分析一下原因：
	要分析这个，首先要看一下原来的sudo的权限是啥样的，如下：
	-rwsr-xr-x 1 root    root       136808 1月  21  2021 sudo
	
	这个权限中的s表示：其他用户执行文件时，具有与所有者相当的权限，所以当我们sudo的时候，就相当于我们就是root，当然不太完整，哈哈。我们平时一般用sudo就可以干很多事情了，那么如果改成了777，就会出现上述问题。
	再看sudoers
	-r--r-----  1 root    root        813 7月  22 18:32 sudoers

	它的权限是非常低的，只有root可以修改它，如果是777，那就太高了，回报上述的错误。
	所以平时不要用太多777，以免发生类似的问题。

方法二:

	其实推荐用方法二啊，因为方法二解决问题比较彻底，而且以后不会有后顾之忧，
	就是先用方法一把数据全部弄出来之后，然后重新部署，这样虽然初期浪费了很多时间，但是，杜绝了后续再因为方法一解决问题不彻底而造成的问题。

事后总结反思：

	这次的问题是因为装机部署的操作失误，导致了后来发现了这个错误，想要改正，却没有注意观察/opt/work-namespace文件的挂载位置。亦不应该赋予任何文件777权限。我倒是每次挂载完之后都会确认，这次是没有看清楚。
	要写出来一个检查重要的系统配置的脚本，在初期部署完成后就要运行一下，尽可能让问题早点暴露出来。尽量减少后续发生大错误的可能。并且要把现有的所有的服务器的配置都过一遍，运维就应该保证服务的正常运行和环境的稳定，并且尽量满足开发者的需求。
	从理论到生产的过程，任重而道。远作为一名自称为专业的人士，更应该对自己的工作有更好的态度和责任感。
	用更专业的知识来尽快从坑里出来，听取其他人的建议来尽量避免踩坑，踩过坑后要反思总结，以后能不能看到这个坑，让这个坑自己暴露出来。