root can do everything, others (with userid != 0) can't do anything. But anyone who has write access to the containing folder is allowed to delete the file. The owner can of course always change the flags and regain access anytime.

greybox:~ septi$ touch foo
greybox:~ septi$ chmod 000 foo
greybox:~ septi$ ls -l foo
----------  1 septi  staff  0 Apr  8 12:28 foo
greybox:~ septi$ cat foo
cat: foo: Permission denied
greybox:~ septi$ sudo ls -l foo
Password:
----------  1 septi  staff  0 Apr  8 12:28 foo
greybox:~ septi$ 

There is a manual page for chmod here.

Basically, look at this table on that page:

You can change the tick boxes, so that different people have different permissions.

Owner is the permissions on that file of the owner of the folder - usually the user that has created them - can be changed with chown.

Group is the permissions on that file of the group of the folder - can be changed with the chown or the chgrp commands.

Other is the permissions on that file of everyone who does not fall into the above two categories.

So running chmod 600 /PATH/TO/FILE will change the permissions so that only the owner can read the file, and write to it.

You can also do the same for folders, but by using chmod -R 600 /PATH/TO/FILE so the contents of the folder is the same as well.

The thing is, if you try entering it as 000:

Then no one can access or write to the file, except root, and the owner if they change the permissions again. This can work, but there is not much point to it as:

• Anyone who is logged in as the owner could remove the file.
• They could change the permissions back again, either by chmod, or by & Properties
• If they are not the owner of the file, you do not need to chmod 000 .., just use chmod 600 ..

So if you want to stop people accessing the file, encrypting the file with a password would be the better idea. So to stop people accessing a file or folder, open Archive Manager, and click New - create one that you can encrypt (under Other Options) - I use .7z, as then you can encrypt the file list to. Then type the password you want to use.

Then you can add files:

Then you have an encrypted archive with your files secure inside - though it can still be deleted...

If you administer the server, you have terminal access. Change the settings for the e-mail system or set up a cron script to regularly clean out the desired folders.

Basically, rootness trumps permissions.

Permissions 000 means only root can read or write the file.

I'm not aware of any extra special use for the combination of root ownership and 000 permissions.

Even as root, you can't execute files that have no x permission bit set. What you can do though is call ld.so on it (provided they're dynamically linked executables):

$ echo /lib/*/ld*.so
/lib/i386-linux-gnu/ld-2.27.so /lib/x86_64-linux-gnu/ld-2.27.so

Use the one that matches the architecture of chmod executable. In my case the x86_64 one:

sudo /lib/x86_64-linux-gnu/ld-2.27.so /bin/chmod 755 /bin /bin/chmod

Or call something in /usr/bin or elsewhere to do the chmod like perl:

sudo perl -e 'chmod 0755, "/bin", "/bin/chmod"

Beware when restoring permissions that some files in /bin like mount or su are meant to have permissions other than 0755.

If you've rebooted, however, you might not be able to get to the point where you can run perl or ld.so though. You can fix things from the initramfs though (pass an incorrect root directory to get a recovery shell in the initramfs; see also the break=bottom or break=init kernel parameter on Debian, for the initramfs to give you a shell after the root file system was mounted (read-only though)). Or boot your VM from a live CD image, or fix by mounting the VM file system on the host as others suggested.

Fixing the initramfs way:

In grub, edit the boot entry and remove the root= parameter from the linux command:

setparams 'Ubuntu, with Linux 3.2.0-27-generic'                          
                                                                         
recordfail                                                               
gfxmode $linux_gfx_mode                                                  
insmod gzio                                                              
insmod ext2                                                              
set root='(hd1)'                                                         
search --no-floppy --fs-uuid --set=root dc02b07c-88ef-4804-afe0-4f02db2\ 
94561                                                                    
linux /boot/vmlinuz-3.2.0-27-generic                                     
initrd /boot/initrd.img-3.2.0-27-generic                                 
                                                                         

Ctrl-X to boot. Ubuntu's initramfs won't find the root file system so start a recovery sh. Then mount the root filesystem (in my case /dev/vdb, adapt to your machine) and fix things there:

Target filesystem doesn't have requested /sbin/init.
No init found. Try passing init= bootarg.


BusyBox v1.18.5 (Ubuntu 1:1.18.5-1ubuntu4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) mkdir /x
(initramfs) mount /dev/vdb /x
[   48.430071] EXT3-fs (vdb): error: couldn't mount because of unsupported optio
nal features (240)
[   48.477406] EXT4-fs (vdb): recovery complete
[   48.477747] EXT4-fs (vdb): mounted filesystem with ordered data mode. Opts: (
null)
(initramfs) chmod -R 755 /x/bin
(initramfs) umount /x
(initramfs) reboot

Once booted, fix the permissions of the files that are not meant to have 755 permissions by comparing with another system.

Fixing by running python as init:

In grub, edit the boot entry, this time keep the root= parameter, change ro to rw and add a init=/usr/bin/python:

setparams 'Ubuntu, with Linux 3.2.0-27-generic'                          
                                                                         
recordfail                                                               
gfxmode $linux_gfx_mode                                                  
insmod gzio                                                              
insmod ext2                                                              
set root='(hd1)'                                                         
search --no-floppy --fs-uuid --set=root dc02b07c-88ef-4804-afe0-4f02db2\ 
94561                                                                    
linux /boot/vmlinuz-3.2.0-27-generic root=UUID=dc02b07c-88ef-4804-afe0-\
4f02db294561 rw init=/usr/bin/python
initrd /boot/initrd.img-3.2.0-27-generic                                 

Then, at the python prompt:

Begin: Running /scripts/init-bottom ... done.
Python 2.7.3 (default, Apr 20 2012, 22:39:59)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.chmod('/bin/sh',0755)
>>> os.chmod('/bin/chmod',0755)
>>> os.execl('/bin/sh','sh')
sh: 0: can't access tty; job control turned off
# chmod -R 0755 /bin
# mount -o remount,ro /
[  100.704720] EXT4-fs (vdb): re-mounted. Opts: errors=remount-ro
# exec /sbin/init

Again, once booted, fix the permissions of the files that are not meant to have 755 permissions by comparing with another system.

What's wrong?

Nothing. Removing all permissions from a file does not prevent deletion or renaming - those are controlled by the permissions of the containing directory (Desktop, in this case). If you want to prevent deletion or renaming, remove write permissions from the directory:

chmod a-w Desktop

Or make the files immutable:

sudo chattr +i Desktop/*.gif

rm will ask you if you want to delete an immutable file, but it can't:

$ rm foo
rm: remove write-protected regular file ‘foo’? y
rm: cannot remove ‘foo’: Operation not permitted

Barring some use of ACLs outside the basic permission system, a chmod 000 can be undone without extra authority. The permission bits control access to the contents of the file, but they do not control write access to the permission bits themselves. Typically, root and the file's owner always have write access to the permission bits. So, you should be able to ‘recover’ the file, as long as you can take actions as the file's owner.

$ id -u                                       
501
$ echo foo > foo                              
$ stat -f '%u %p' foo; cat foo                
501 100644
foo
$ chmod 000 foo
$ stat -f '%u %p' foo; cat foo
501 100000
cat: foo: Permission denied
$ chmod 644 foo
$ stat -f '%u %p' foo; cat foo
501 100644
foo

If you have shell access and your shell user owns the file (or your user can change to the file's owner (su/sudo/…)), then just chmod it back by hand. Otherwise, if you can edit the PHP script (and the PHP runs as the file's owner), just edit it to chmod the file to the desired permissions.

It can write the same as it can read. Being root trumps these. But with execution it's a different story. If a file is not marked as executable, then it's not considered executable. However, once it's marked executable, it doesn't have to be readable for root to be executed (if it is a script). Unlike it is with the regular users.