When automounting removable media via the -media map, there is no way to specify filesystem permissions to the subdirectories of /media other than the default "drwxr-xr-x root:wheel" which prevents unprivileged users from writing to the removable flash drives etc. Permissions of the /media directory are not being inherited.
When you mount a filesystem, permissions on a mountpoint are taken from permissions from the mounted filesystem root directory. Basically: % ll total 6 drwxr-xr-x 3 root wheel 512 Nov 25 13:04 . drwxr-xr-x 23 root wheel 1024 Nov 25 13:04 .. drwxr-xr-x 3 root wheel 512 Nov 25 13:44 md0 trasz@v2:/media % ll total 6 drwxr-xr-x 3 root wheel 512 Nov 25 13:04 . drwxr-xr-x 23 root wheel 1024 Nov 25 13:04 .. drwxr-xr-x 3 root wheel 512 Nov 25 13:44 md0 trasz@v2:/media % cd md0 trasz@v2:/media/md0 % ls -al total 9 drwxrwxrwx 3 root wheel 512 Nov 25 13:47 . drwxr-xr-x 3 root wheel 512 Nov 25 13:04 .. drwxrwxr-x 2 root operator 512 Nov 25 13:46 .snap trasz@v2:/media/md0 % cd .. trasz@v2:/media % ls -al total 9 drwxr-xr-x 3 root wheel 512 Nov 25 13:04 . drwxr-xr-x 23 root wheel 1024 Nov 25 13:04 .. drwxrwxrwx 3 root wheel 512 Nov 25 13:47 md0 In this case, "ls -al" triggered mounting an UFS-formatted md0, which, before the experiment, had "chmod 0777 ." done to its root inode. What I'm getting at - the permissions on autofs nodes shouldn't matter at all; it's the mounted filesystem's permissions that's being used for the access checks. Could you tell me some more about your scenario?
(In reply to Edward Tomasz Napierala from comment #1) > When you mount a filesystem, permissions on a mountpoint are taken from permissions from the mounted filesystem root directory. What permissions are there in the root directory of an msdosfs or exfat filesystem? None. Those filesystems don't support permissions. Therefore those filesystems inherit permissions from the directory they are mounted on (man mount_msdosfs for -m). > Could you tell me some more about your scenario? Try to mount an msdos-formatted flash card (from your camera) by autofs, in a way that unprivileged users could write to it, and you'll see my point.
Okay, now I understand what you mean (for the record: code block at mount_msdosfs.c:202). Again, just like with charsets, the right way would be to set those in auto_master (eg '/media -media -nosuid,noatime,autoro,-M=777,-m=666') or modify /etc/autofs/special_media. I don't we should add permissions support to autofs; it would be hacking around a hack in msdosfs.
(In reply to Edward Tomasz Napierala from comment #3) > just like with charsets, the right way would be to set those in auto_master No, this will break exfat because fuse does not understand the -M and -m options, and /media is common for both msdosfs and fusefs. Won't do. > or modify /etc/autofs/special_media What modifications to /etc/autofs/special_media do you suggest? I guess the stock /etc/autofs/special_media map should provide for group- or even world-writable mounting of removable media. At least that is what users expect: you insert your SD card and then you write to it, or delete files there.
I think "-M=777,-m=666" should be the default for _fstype=msdosfs
World or group writable defaults would be a security risk, e.g. malicious users could plant Trojans on removable media. That's an inherent risk with all writable FAT media, but one to which individual users should have to deliberately expose themselves with due warning. I think the default on filesystems that don't support permissions should remain read-only, in keeping with FreeBSD's "secure by default" convention, but we need a clean, simple method for systems managers to customize them. E.g. something that a slightly more sophisticated /etc/autofs/special_media or mount_* could pick up from a config file, like the numerous flags variables set in rc.conf.
(In reply to Jason W. Bacon from comment #6) > World or group writable defaults would be a security risk, > e.g. malicious users could plant Trojans on removable media. I think actually no, they would not, unless you make all files executable by default ("-m 777" or "-m 755"). "-m 666" should be safe. > I think the default on filesystems that don't support permissions > should remain read-only, I disagree. Mr. Average User expects to be able to write, move and delete files on the SD card, when he inserts it from his camera to his desktop computer.
(In reply to Jason W. Bacon from comment #6) Or autofs can mount removable media with "-o noexec" by default if we are afraid of Trojans.
(In reply to Victor Sudakov from comment #7) You can present those arguments to secteam if you want, but I think that discussion would only delay resolution of the issues we're interested in. Giving sysadmins the tools to easily configure default mount flags as they please will solve this issue without creating liabilities for anyone else, plus we need this anyway for locale settings.
Created attachment 209942 [details] mount_msdosfs hack Here's am ugly proof-of-concept hack for what I think would be a reasonable approach. It's by no means production-ready or even the best implementation but it gets the point across. We might consider doing this sort of thing at the generic mount level, though it's probably not that useful for other filesystem types and suggesting that might meet more resistance. Limiting it to msdosfs seems like the way to go for now. <<<ROOT@orca.acadix>>> /usr/src/sbin/mount_msdosfs 1184 # cat /etc/mount_msdosfs.conf -m 0770 -g operator <<<ROOT@orca.acadix>>> /usr/src/sbin/mount_msdosfs 1185 # mount_msdosfs /dev/da1 /mnt argv[0] = mount_msdosfs argv[1] = -m argv[2] = 0770 argv[3] = -g argv[4] = operator argv[5] = /dev/da1 argv[6] = /mnt argv[7] = (null) <<<ROOT@orca.acadix>>> /usr/src/sbin/mount_msdosfs 1186 # ls -al /mnt total 36 drwxrwx--- 1 root operator 32768 Dec 31 1979 ./ drwxr-xr-x 21 root wheel 1024 Dec 12 20:28 ../
Created attachment 209943 [details] Header to go with patch
I don't think this should be specific to msdosfs. Whatever the mechanism is, we should provide one knob, not separate ones for every filesystem that doesn't support permissions.
As for defaults: one way would be to do what eg DRI does with the 'video' group: have a group that authorizes access to removable media, and set default permissions to limit access to members of that group.
(In reply to Edward Tomasz Napierala from comment #13) Agreed. I'd be inclined to use the operator group for this sort of access.
Created attachment 210141 [details] Generalized default options hack Here's a more generalized patch that can be easily added to any mount command (or any other command for that matter). It requires a trivial change to each individual mount command. This means we could test it in production on mount_msdosfs without any risk to other mount commands, then easily add it to others later if desired. Each configuration file starts with an fstype, as follows: <<<ROOT@orca.acadix>>> /usr/src/sbin/mount_msdosfs 1063 # cat /etc/mount_defaults.conf msdosfs -m 0770 -g operator This is still just a proof-of-concept prototype. If you guys like the idea, I'll clean it up and get it ready for commit. FYI, it seems to me that mount_msdosfs is the only command with read-only permissions. NTFS and exFAT are supported by fusefs ports and get mounted 0777 by default.
As I erroneously posted under PR 241475 yesterday: As for the permissions issues, perhaps the mount directory should default to the ownership of /dev/console, which is set to the user currently running a session. I think this would be more useful than root:wheel. This still leaves some issues for multiuser installations, but I think allowing the local sysadmin to control mount options as described above would take care of most of them. Here's a demonstration of how to set ownership of FAT media to the console user: <<<ROOT@orca.acadix>>> /home/bacon 1068 # grep -A 2 msdos /etc/autofs/special_media "msdosfs") console_owner=$(stat -f "%u" /dev/console) echo "-fstype=${_fstype},nosuid,sync,-u=$console_owner :/dev/${_p}" <<<ROOT@orca.acadix>>> /home/bacon 1069 # ls -al /media/SONY8/ total 33 drwxrwx--- 1 bacon operator 32768 Dec 31 1979 ./ drwxr-xr-x 3 root wheel 512 Dec 24 07:56 ../ I would only suggest applying this approach as a default for autofs or other temporary mount tools. Users mounting via fstab or the command line may want different ownership and permissions and autofs users should have the ability to override it (e.g. via autofs_msdosfs_flags)
(In reply to Jason W. Bacon from comment #16) > as for the permissions issues, perhaps the mount directory should default > to the ownership of /dev/console, I don't think this will make much sense. A modern Unix system is either a graphical desktop (where nobody cares about /dev/console) or a (virtual) server where the only useful console is serial (if used at all other than at installation time).
(In reply to Victor Sudakov from comment #17) >> as for the permissions issues, perhaps the mount directory should default >> to the ownership of /dev/console, > I don't think this will make much sense. A modern Unix system is either a > graphical desktop (where nobody cares about /dev/console) or a (virtual) server > where the only useful console is serial (if used at all other than at > installation time). The point of /dev/console is simply to determine who is currently logged in on the local display. On graphical desktop systems, /dev/console ownership is generally set to the current user by the display manager. If that's not true for a given display manager, there are other ways to determine who is currently running a session. Setting ownership on FAT media to the current user is the most secure way to provide write access to the person who is physically present. I've managed many workstations that are used both as graphical desktop systems and accessed remotely via ssh, so this can be important.
(In reply to Jason W. Bacon from comment #18) Well, I don't know, I'm sitting now in an xfce session (running from startx), and # ls -al /dev/console crw------- 1 root wheel 0x4 3 янв. 19:51 /dev/console
In Windows, when you insert a removable drive with a FAT/exFAT filesystem (which is most likely to be found on an SD card from a camera or smartphone), any Windows user can write to it. I think this behavior is expected by users, and quite in line with the absence of file permissions on FAT. So I think we should emulate this behavior in FreeBSD due to the POLA.
If you're not running a display/login manager, then no, there won't be anything under /dev owned by you. As an alternative, we could grep "ps auxw" for your window manager, or just accept that unusual cases like this won't benefit from this feature. They certainly won't be harmed by it either, though, provided that the local sysadmin has control over mount options. I did a little more digging and found that sddm and gdm set ownership of ttyv8 rather than console. Regardless of the login manager, it's not hard to figure out who's running the local session. I think we should aim to do much better than the security model of Windows. There's a big difference between what typical users expect and what's secure. FreeBSD is advertised as secure-by-default, which is why many people use it instead of Windows. Any world-writable directory is a tool for malicious users, e.g. a hacker who compromised a user's password. They could put malicious code on it, which represents a danger even if it cannot be run directly from the external media due to a noexec mount. It would become a danger when copied to another directory or when the media are mounted on another system that does not use noexec. In summary, what I'm suggesting is: 1. By default, set ownership of external permission-less media to the current local display owner where it's convenient 2. Give the local sysadmin full control over mount options in any case so they can override the defaults and set other features such as locale This will ensure that external media can be made writable to whomever they should be.
I should add that I would rather see a solution that's acceptable to everyone ASAP than to have the ideal solution hung up in committee indefinitely. While limiting access to the local user by default would be ideal, I think giving the sysadmin control over mount options is the most important part of any solution. Then everyone can have what they want and there won't be a need to waste time on future debates. So an implementation of #2 above that allows me to configure *my* system as described in #1 would get my thumbs up. For the sake of FreeBSD's reputation as a secure OS, I'll always argue against any defaults that create world-writable directories (besides tmp), but I'd rather continue that discussion after this issue is mitigated. I'll review what we have on the table and follow up with an enhanced patch if necessary.
Created attachment 210468 [details] Patch to allow custom mount flags via special_media This new patch shows how we could allow the local sysadmin to customize mount flags for any fstype. It only applies to autofs, but I see no reason not to support custom flags both here and within the mount commands. Maybe we could start with this approach as a proof-of-concept and see if the idea trickles down to mount_* if people want to duplicate it in other mounting methods.
Created attachment 210469 [details] Example msdosfs customization script Example script to work with the special_media patch, with generic defaults that should work on any system and documentation for setting mount ownership as I suggested earlier.
Created attachment 210470 [details] Replace printfs from testing with logger
This autofs thing is unusable for any practical purpose. Use sysutils/automount from ports for removable media, it works out of the box.