#296836 chmod does not change permissions but gives no error message on VFAT

Package:
coreutils
Source:
coreutils
Description:
GNU core utilities
Submitter:
Juergen Katins
Date:
2018-12-14 18:09:06 UTC
Severity:
normal
#296836#5
Date:
2005-02-25 00:30:18 UTC
From:
To:
I am trying to get write acces to a windows vfat partition. During this
I changed permissions with chmod. Seemingly chmod did the job but in
reality it did not. This is feigning functionality! See this:

katzes:~# chmod 0777 /windowsC
katzes:~# ls -l /
total 154
drwxr-xr-x    2 root root  4096 Feb 24 14:58 bin
drwxr-xr-x    3 root root  4096 Jan 14 11:26 boot
..
..
..
lrwxrwxrwx    1 root root    24 Jan 11 11:37 vmlinuz.old ->
boot/vmlinuz-2.6.8-1-386
drwxr--r--   38 root root  8192 Jan  1  1970 windowsC

As you can see chmod accepted the order to change permissions, but did
nothing.


BTW: Could you please encourage the debian team to replace this horrible
bug report program.

#296836#10
Date:
2005-07-01 09:49:40 UTC
From:
To:
Error is worse than I thoght:
chmod is not only suppressing an error message, it is even reporting a
success!




katzes:/# stat windows
  File: `windows'
    Size: 4096            Blocks: 8          IO Block: 4096   directory
    Device: 2141h/8513d     Inode: 1           Links: 6
    Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/
    root)
    Access: 1970-01-01 01:00:00.000000000 +0100
    Modify: 1970-01-01 01:00:00.000000000 +0100
    Change: 2005-06-30 23:44:19.169147744 +0200
katzes:/# chmod  777 windows -v
    mode of `windows' changed to 0777 (rwxrwxrwx)
katzes:/# stat windows
  File: `windows'
    Size: 4096            Blocks: 8          IO Block: 4096   directory
    Device: 2141h/8513d     Inode: 1           Links: 6
    Device: 2141h/8513d     Inode: 1           Links: 6
    Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/
    root)
    Access: 1970-01-01 01:00:00.000000000 +0100
    Modify: 1970-01-01 01:00:00.000000000 +0100
    Change: 2005-06-30 23:51:20.426106952 +0200

As you can see: After chmod has reported having changed the rights to
rwxrwxrwx they are still rwxr-xr-x.

A program not doing what it is supposed to do is bad enough but a
program lying to the user is even worse!

#296836#15
Date:
2005-07-01 16:18:47 UTC
From:
To:
Jürgen Katins wrote:

Inode one seems really strange to me.  That would not be a normal
filesystem.  What type of filesystem is this?  You can use 'df -T' to
show this information.  Looks wrong to me.

What does an strace of the run show?

  strace -e chmod chmod -v 0777 windows

If it shows something like this, then the kernel chmod(2) call
reported success and the problem is in your kernel.

  chmod("testfile", 0777)                        = 0

I think the problem is not chmod but instead that you have a problem
with the filesystem upon which it is being run.  If the filesystem is
reporting erroneous information then the problem is there.

The strace information should show the kernel system call return code
and clarify the location of problem.

Bob

#296836#22
Date:
2005-10-14 10:05:00 UTC
From:
To:
severity 296836 normal
tags 296836 wontfix
stop

This is how chmod works when operating on vfat filesystems (which
don't have real UNIX permission bits).

jdthood@turmeric:/mnt/hda2/tmp$ ls -l aaa   # on vfat filesystem
-rwxr-xr-x  1 root root 0 2004-12-18 09:17 aaa
jdthood@turmeric:/mnt/hda2/tmp$ sudo chmod ugo+w aaa && echo Success
Success
jdthood@turmeric:/mnt/hda2/tmp$ ls -l aaa
-rwxr-xr-x  1 root root 0 2004-12-18 09:17 aaa
jdthood@turmeric:/mnt/hda2/tmp$ cd /tmp   # to ext3 filesystem
jdthood@turmeric:/tmp$ touch aaa
jdthood@turmeric:/tmp$ ls -l aaa
-rw-r--r--  1 jdthood jdthood 0 2005-10-14 12:02 aaa
jdthood@turmeric:/tmp$ sudo chmod ugo+w aaa && echo Success
Success
jdthood@turmeric:/tmp$ ls -l aaa
-rw-rw-rw-  1 jdthood jdthood 0 2005-10-14 12:02 aaa

#296836#27
Date:
2007-01-17 15:31:13 UTC
From:
To:
hi

'man mount', regarding FAT mounts , explains the 'quiet' flag as follows:

       quiet  Turn on the quiet flag.  Attempts to chown or chmod files do not
              return errors, although they fail. Use with caution!

I gave it a try: it seems that 'chown' works as documented:
when 'quiet' is not set, indeed

# chown D /media/usbdisk/promemoria.pdf ; echo $?
chown: changing ownership of `/media/usbdisk/promemoria.pdf': Operation not permitted
1

But 'chmod' does never return an error on VFAT filesystem,
(in all the way that I tried it);
so maybe a small change in documentation may be useful; something as

       quiet  Turn on the quiet flag.  Attempts to chown files do not
              return errors, although they fail. Use with caution!

              Beware that, in general, 'chmod' will not return errors on VFAT,
              but will mostly fail to do what you expect it to do, due to limitations
              in the filesystem.


a.

#296836#34
Date:
2018-12-14 18:07:34 UTC
From:
To:
I confirm that the behavior of the function are not consistent. This problem have also chown. I have the same problem with my vfat windows permissions. But chmod and chown they have return code 0 and they not change anything even as root or user level. These commands must verify their executions and return 0 when something is wrong is not a good programming practice.

$cat /ect/debian_version
9.6

$ strace -e chmod chmod -v 0777 sf_Java11Machine
der Modus von 'sf_Java11Machine' wurde von 0770 (rwxrwx---) in 0777 (rwxrwxrwx) geändert
+++ exited with 0 +++

$ ls -la

insgesamt 15
drwxr-xr-x  5 root root   4096 Nov 26 23:53 .
drwxr-xr-x 21 root root   4096 Nov 16 14:10 ..
drwxr-xr-x  2 root root   4096 Nov 16 14:06 cdrom
drwxrwx---  1 root vboxsf    0 Nov 30 12:26 sf_Java11Machine
dr-xr-xr-x  6 root root   2226 Nov  8 20:58 sr0

$ strace -e chown chown -v frank sf_Java11Machine

der Eigentümer von 'sf_Java11Machine' wurde von root in frank geändert
+++ exited with 0 +++
frank@antix1-java11:/media

$ ls -la
insgesamt 15
drwxr-xr-x  5 root root   4096 Nov 26 23:53 .
drwxr-xr-x 21 root root   4096 Nov 16 14:10 ..
drwxr-xr-x  2 root root   4096 Nov 16 14:06 cdrom
drwxrwx---  1 root vboxsf    0 Nov 30 12:26 sf_Java11Machine
dr-xr-xr-x  6 root root   2226 Nov  8 20:58 sr0