Is .bashrc executed by the program which mounts the volume in KDE Plasma?
No.
At most, when the window manager is initialised, it’ll read ~/.profile.
Yes; the exFAT SD card is either in the camera or, being read by the NAS “brick” (ARM, embedded Linux, neither SUSE nor openSUSE) – licensed exFAT driver …
Then the umask command should not be the problem because in my case it is in .bashrc.
Example: 4 GB vFAT SD card, mounted by means of the KDE Device Notifier:
> su test002
Passwort:
> whoami
test002
> groups
test-user cdrom video
>
> mount
.
.
/dev/sdj1 on /var/run/media/**xxx**/3433-3430 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)
>
> cd /var/run/media/
>
> ls -al
total 0
drwxr-xr-x 3 root root 60 17. Apr 14:45 .
drwxr-xr-x 36 root root 1080 17. Apr 14:52 ..
drwxr-x---+ 3 root root 60 17. Apr 14:45 **xxx**
test002@eck001:..run/media> ls -al **xxx**/
ls: cannot open directory '**xxx**/': Permission denied
>
> getfacl **xxx**/
# file: **xxx**/
# owner: root
# group: root
user::rwx
user:**xxx**:r-x
group::---
mask::r-x
other::---
>
The user who mounted the SD card by means of the KDE Device Notifier has a different view:
> whoami
**xxx**
> groups
users news cdrom video
>
> cd /var/run/media/
> ls -al
total 0
drwxr-xr-x 3 root root 60 Apr 17 14:45 .
drwxr-xr-x 36 root root 1080 Apr 17 14:52 ..
drwxr-x---+ 3 root root 60 Apr 17 14:45 **xxx**
> cd **xxx**/
> ls -al
total 32
drwxr-x---+ 3 root root 60 Apr 17 14:45 .
drwxr-xr-x 3 root root 60 Apr 17 14:45 ..
drwxr-xr-x 3 **xxx** users 32768 Jan 1 1970 3433-3430
>
AFAICS, there’s no need to change the default permissions on removable drives: FUSE sets the ownership to “root”, disallows “other” access and, places an ACL on the (user’s name) directory which allows the user who triggered the FUSE mount to access (read from and write to) the (removable) drive …
- Nobody else on the system can access that removable drive …
I am not quite sure how to use the info you share. Can you clarify (hopefully in the context of exfat)?
Just to note: the umask which I have in .bashrc was not added (years ago) in relation to mounting of external drives.
Backtracking to your original question, AFAICS the answer is:
- Change the settings of FUSE, especially with respect to the ACL it places on the ‘/run/’ directory created for the user who has triggered the mount via FUSE.
- Don’t worry about the executable bit “seen by a UNIX®/MAC OS/Linux/Android/BSD system” when a Microsoft®/Redmond file system is mounted …
How do I do this please? (where are these settings?)
Don’t worry about the executable bit “seen by a UNIX®/MAC OS/Linux/Android/BSD system” when a Microsoft®/Redmond file system is mounted …
I do worry because I don’t want files (e.g. text files containing scripts) which must not be executable to be randomly given the execute permission.
BTW today I tried with a 64Gb CF card formatted in the same camera, using the same card reader and for it I got:
~]: mount | grep sd
...
/dev/sde1 on /run/media/████/EOS_DIGITAL 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,uhelper=udisks2)
/dev/sde1 on /var/run/media/████/EOS_DIGITAL 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-r
~]: dir /run/media/$USER
total 32
drwxr-xr-x 5 ████ users 32768 Jan 1 1970 EOS_DIGITAL
The permissions with that card were as expected: 0755 for dirs and 0644 for files with owner <myusername>:users. So it seems like an issue with exfat only.
I have no idea why
I also tried another (USB2) reader with both cards. That didn’t affect the result.
Content of /proc/mounts is entirely misleading for mount.exfat-fuse - it shows exactly the same content irrespective of actual mount options used. Show output of “ps -efwww | grep exfat”.
~]: ps -efwww | grep exfat
root 27278 1 0 00:07 ? 00:00:00 /sbin/mount.exfat /dev/sdf1 /run/media/████/EOS_DIGITAL -o rw,nodev,nosuid,uid=1000,gid=100,iocharset=utf8,namecase=0,errors=remount-ro,umask=0077,uhelper=udisks2
████ 27286 27182 0 00:07 pts/0 00:00:00 grep --color=auto exfat
OK, that explains permissions (I wondered about 700 permissions part). As for executable bit - that is how FUSE exfat driver works. The only way to clear executable bit is to use umask argument, something like umask=0177. Options are set by client that initiates mount, in your case probably KDE. Whether it provides any means to configure mount options I really do not know (last time I looked - long ago - it did not).
And regarding title of this tread - there is no “defalut permissions for removable drives” at all. Each client that initiates mount passes options as this client deems appropriate.
Too bad.
And regarding title of this tread - there is no “defalut permissions for removable drives” at all. Each client that initiates mount passes options as this client deems appropriate.
Then how does one change the mounting client? Is that possible? (or is the only option manual mounting as root and manual setting of permissions)
AFAICS, the options are as follows:
- FUSE mount from the CLI:
“/usr/sbin/mount.fuse spec dir -sfnv] -o options] -t type.subtype]”
with the option “default_permissions” – see the “fuse(8)” and “mount(8)” man pages.
- Take a look at what “AppArmor” is doing: <https://doc.opensuse.org/documentation/leap/security/html/book.security/part.apparmor.html>.
- Modify the FUSE code and rebuild the “fuse” RPM package.
AppArmor is something I still need to learn about and modifying code is beyond my abilities. So using the first option I am reading that fuse(8) man page says:
default_permissions
By default FUSE doesn’t check file access permissions, the filesystem is free to implement it’s
access policy or leave it to the underlying file access mechanism (e.g. in case of network
filesystems). This option enables permission checking, restricting access based on file mode.
This is option is usually useful together with the allow_other mount option.
Does this mean that in order to have permissions as in the case of vfat one should not use the mounting functionality of KDE but do it from command line each and every time? All this is quite unclear to me.
These both work (but need root):
# mount.exfat-fuse -o umask=177,dmask=077,uid=1000,gid=100 /dev/sdf1 /mnt
# mount.exfat-fuse -o umask=133,dmask=022,uid=1000,gid=100 /dev/sdf1 /mnt
This does not seem to work (as user) and I have no idea why:
~]: fusermount -o default_permissions /dev/sdf1
fusermount: old style mounting not supported
Yes.
You could define a “sudo” for the mount or, add your user to the group “disk” – take a look at the ownerships of “/dev/sd*” …
This is looking bad:
> ls -l /usr/bin/fusermount
-rwsr-xr-x 1 root trusted 31560 10. Mai 2017 /usr/bin/fusermount
>
> file /usr/bin/fusermount
/usr/bin/fusermount: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.0.0, BuildID[sha1]=73ac43bf35e5a1f378098537dc81ca119e97bf97, stripped
>
Whether or not, adding the user to the group “trusted” would help – don’t know.
Executing “fusermount -o default_permissions” from the user user “root” didn’t help – same error: “fusermount: old style mounting not supported”.
It seems that, the openSUSE “fusermount” is only good for unmounting file systems …
Thanks for the info. This whole thing really looks buggy. Previously I could simply insert the card and have right permissions. Now all that gym…
Security can be annoying:'(
When exactly was this “previously”? What has changed since then?
Some time in December 2017.
I don’t know what has changed since then (except that I have been running ‘zypper up’)
This still seems to be an issue in Leap 15.0 with the only difference that now everything (files and dirs) is 777.