Лучшее предложение, о котором я могу думать, состоит в том, чтобы создать установку LVM с физическими томами, группами объема и логическими томами, затем смонтировать те логические тома как файловую систему Вашего VM через iSCSI.
Это позволит Вам изменить размер логического тома и затем всего, что необходимо было бы сделать, после этого перезапуск iscsi демон и программное обеспечение виртуальной машины, и проверьте, что это имеет новые параметры размера, и затем измените размер файловой системы гостя для соответствия.
Разделение работало бы со стандартным HDD, как это - то, как LV появился бы гостю виртуальной машины.
Править: не берите в голову это, я получил ложное впечатление, Вы выполняли VMware в соответствии с Linux, не Linux под VMware.
First of all a minor terminology nitpick: chmod
doesn't remove permissions. It CHANGES them.
Now the meat of the issue -- The mode 777
means "Anyone can read, write or execute this file" - You have given permission for anyone to do (effectively) whatever the heck they want.
Now, why is this bad?
login
program that lets them in every time).rm -r /
and it's all over. The OS was told to let them do whatever they wanted!sudo
, sendmail
, and a host of others simply will not start any more. They will examine key file permissions, see they're not what they're supposed to be, and kick back an error message.ssh
will break horribly (key files must have specific permissions, otherwise they're "insecure" and by default SSH will refuse to use them.)777
is actually 0
777
. Among the things in that leading digit are the setuid
and setgid
bits./tmp
and /var/tmp
The other thing in that leading octal digit that got zero'd is the sticky bit
-- That which protects files in /tmp
(and /var/tmp
) from being deleted by people who don't own them.rm -r /tmp/*
, and without the sticky bit set on /tmp
you can kiss all the files in that directory goodbye./dev
/proc
and similar filesystems/dev
is a real filesystem, and the stuff it contains are special files created with mknod
, as the permissions change will be preserved across reboots, but on any system having your device permissions changing can cause substantial problems, from the obvious security risks (everyone can read every TTY) to the less-obvious potential causes of a kernel panic.Credit to @Tonny for pointing out this possibility
Credit to @Tonny for pointing out this possibility
.
in their PATH
environment variable (you shouldn't!) - This could cause an unpleasant surprise as now anyone can drop a file conveniently named like a command (say make
or ls
, and have a shot at getting you to run their malicious code.Credit to @RichHomolka for pointing out this possibility
chmod
will reset Access Control Lists (ACLs)Credit to @JamesYoungman for pointing out this possibility
Will the parts of the system which are already running continue to run? Probably, for a while at least.
But the next time you need to launch a program, or restart a service, or heaven forbid REBOOT the box you're in for a world of hurt as #2 and #3 above will rear their ugly heads.
One major thing is that there are many tools like ssh/sudo that check the filesystem permissions for key config files. If the permissions are wrong, these tools are designed to fail, as this would indicate a serious security problem. On my Debian test system and perhaps on others, the ability to login fails, probably because the login binary or something in PAM has permission checks.
So it isn't really that the system is destroyed -- it's that many tools are designed to immediately fail when the permissions are wrong.
If you reboot a system after doing a chmod 777 -R /
it will boot, and you can start processes that don't have explicit permission checks. So the system isn't really dead, just somewhat unusable by-design.