I just noticed that after mounting an SD card all files and dirs in it are with 700 permissions which is wrong (a PDF is not executable). IIRC it wasn’t like that before.
What could be the reason for this change and how can I set default permissions for removable storage?
I can not reproduce this on my Leap 42.3 system. The bits set are rw-r–r-- (as it was on earlier openSUSE versions).
So why is it different at your’s?
While I admit that a desktop mount should not set any x-bits (for security reasons, do not execute a file from an external, untrusted source), I think your talking about PDF files has no ground. The mount is really not going to check the contents of all files to find out if setting an x-bit might be useful.
We don’t even know what the file system on the SD card is. F.e. FAT cannot write linux permissions, and FAT is what lots of cameras ( EOS = Canon ) use/used.
Which is one of the reasons I requested the output of mount. Vague descriptions with out all the necessary supporting definitive information leads to speculation.
The 2 entries which appear in the command’s output after mounting the SD card are:
/dev/sdf1 on /run/media/<myusername>/EOS_DIGITAL type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
/dev/sdf1 on /var/run/media/<myusername>/EOS_DIGITAL type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
~]: dir /run/media/$USER
total 256
drwx------ 1 <myusername> users 262144 Jan 1 1970 EOS_DIGITAL
That’s what I am trying to find too. Which is even more interesting - I noticed this just recently. Previously (think months and years) it was not like that. FWIW in .bashrc I have ‘umask 0077’ but it has always been like that, so that is not something new or recently changed.
While I admit that a desktop mount should not set any x-bits (for security reasons, do not execute a file from an external, untrusted source), I think your talking about PDF files has no ground. The mount is really not going to check the contents of all files to find out if setting an x-bit might be useful.
I mentioned PDF just to say that it is regardless of file type, just like you explained.
It is a 32GB SD card formatted inside the Canon camera. mount and ‘df -T’ show that type is fuseblk.
I used ‘sdf’ instead of ‘sd’ for grep filtering because there are quite a few HDD partitions starting with sd*
As far as I see the FS is exfat. (the card is in write protected mode, so the other message is correct)
~]: mount | grep sdf
/dev/sdf1 on /run/media/<myusername>/EOS_DIGITAL type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
/dev/sdf1 on /var/run/media/<myusername>/EOS_DIGITAL type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
~]: su -
Password:
# umount /dev/sdf1
# mount | grep sdf
# mount /dev/sdf1 /mnt
FUSE exfat 1.2.7
WARN: '/dev/sdf1' is write-protected, mounting read-only.
# mount | grep sdf
/dev/sdf1 on /mnt type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
#
After that /mnt and all files and dirs in it are with permissions 777 and ownership root:root.
I noticed that too. But the files and dirs inside the mount dir are with correct timestamps.
The never ending exFAT licensing issue and the "US American authorities can’t prosecute the ‘located somewhere in Russia’ software developer
" case.
Be that as it may, the bottom line is, exFAT is not a UNIX®-like file system and therefore, doesn’t understand the UNIX® and, anything that looks or smells like UNIX®, file system attribute bits – the things which make our life much easier, more productive and more secure …
[HR][/HR]Therefore, my suggestion is, given a “modern” UNIX®-like system – the thing we call “Linux” – forget the things we did years ago on UNIX® systems such as setting umask bits in the shell initialisation files, and simply use the more modern things such as FUSE “as is”, given that we currently rely on other system mechanisms such as “Authorization Manager” (for example ‘polkit’) to deal with system security issues …
I have no idea how to use this info. Can you explain please?
As I said - previously I haven’t seen such issue, I noticed it just recently. The last time I mounted this same card was in December and I didn’t see such weird permissions. So I am not quite sure it is an issue with exfat itself. But I am not an expert.
Taking a SanDisk Extreme Pro 32 GB SD card formatted in a Sigma sd Quattro and plugging it into a Hama USB 3.0 Card Reader, with a KDE Plasma 5 desktop and the “normal” (for KDE) access via the Device Notifier – “Open with File Manager”, I get the following results:
Mount:
/dev/sdj1 on /var/run/media/xxx/SD QUATTRO type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)
I do not set ‘umask’ in my ‘.profile’ and, I haven’t changed the default system setting …
[HR][/HR]My 64 GB card is exFAT and I read it via my QNAP NAS (also a Linux) – exFAT license paid …
It may be that, the Linux FUSE exFAT driver also got updated recently which may, therefore, be the cause, possibly …
Given a different (QNAP) system (ARM CPU … ) and, an official, licensed, exFAT driver – possibly the same one as that used by the automotive industry but, don’t really know …
SanDisk Extreme PRO 64 GB formatted in the Sigma sd Quattro:
Mount:
/dev/sdd1 on /share/external/DEV3301_1 type ufsd (rw,iocharset=utf8,dmask=0000,fmask=0111,force)
Fine, but umask 0077 basically means that file permissions will be 700, exactly like you’ve reported. If this was not the case earlier, then it now looks more like a fixed bug to me.