当应用程序需要访问特定文件时，正确的方法是什么？

Question

今天，我遇到了一个有趣的场景(至少对我来说--Linux中的新手)。我把我的无人机连接到我的Linux电脑上。无人机配置软件(Betaflight)无法连接到无人机。谷歌的快速搜索解决了这个问题。基本上，当我用USB电缆连接无人机时，就会创建一个文件：/dev/ttyUSB0，它具有660权限。文件的所有者是root，文件的组是uucp。因此，简单的解决方案是将该文件chmod转换为666。然而，这在我的脑海中引起了一些问题。

我刚刚向每个人添加了r和w权限，这似乎太过了。或者，我认为我可以将Betaflight添加到uucp组中，这看起来很愚蠢，因为它是一个重要的组，或者使用sudo运行它，这似乎更糟糕。

处理这件事的正确方法是什么？从逻辑上讲，添加一条规则使Betaflight能够访问这个特定的文件是有意义的。我只是好奇什么是"Linux方式“。我不想让一个随机的应用程序对我的操作系统进行过多的访问，我也不想让任何应用程序/用户访问特定的文件。

Answer 1

欢迎Andrzej来到Unix&Linux，

如果您想将您所给予的权限降到最低，我建议您：

1. 创建一个专门的组(让我们将其命名为drone)：addgroup drone
2. 将/dev/ttyUSB0更改为组drone：chgrp drone /dev/ttyUSB0
3. 将无人机配置软件(我们称之为/usr/bin/foo)更改为组drone，并启用setgid位：chgrp drone /usr/bin/foo; chmod g+s /usr/bin/foo
4. 可以选择不允许other执行配置软件，并授予专用用户(S)(我们称之为user1)使用文件ACLs：chmod o-x /usr/bin/foo; setfacl -m u:user1:r-x /usr/bin/foo执行配置软件的权限。

您可以使用sudo替换3和4，允许专用用户(S)作为组drone运行配置软件。您可以在/etc/sudoers中添加：

user1 ALL=(:drone) /usr/bin/foo

然后将其用作user1：sudo -g drone foo

Answer 2

不同的Linux发行版可能会有不同的答案。

在早期Unix时代，当串行线路和调制解调器是计算机之间最常见的联网方式时，电子邮件和文件传输由一个称为Unix到Unix副本( uucp )的软件套件处理。为了确保常规用户不会在系统之间安排电子邮件传输之类的事情，经常将对用于传出连接的串行端口的访问分配给一个通常称为uucp的特殊组。uucp套件的程序被分配了一个setgid uucp权限，这将允许那些程序-并且只有那些程序可以访问输出的串行端口而没有根权限。

普通用户可以运行uucp套件的一些工具，但是这些工具本身包含必要的检查以避免恶作剧。

显然，您的Linux发行版仍然遵守这个旧的命名约定。在现代系统上，实际的uucp软件套件不太可能被使用，因此uucp组可以用来控制对串行端口的访问，无论对系统所有者来说是什么方式。有些发行版使用一个具有不同名称的组(如dialout )来管理串口，因为名称uucp对于任何不知道这一点Unix历史的人来说都是不透明和不直观的。

我认为一些Unix规范曾经要求(或至少建议) uucp组应该始终作为一个预定义的系统组存在于任何兼容的类Unix系统上。

有些发行版实际上预先定义了许多组，这些组可用于允许特定用户访问特定类型的设备，如Debian中的cdrom、audio、video、plugdev或scanner及相关发行版。

/dev/ttyUSB0不仅仅是一个常规文件:它是一个设备节点。在现代Linux发行版中，设备节点由udev管理，并存储在基于RAM的文件系统中，因此，如果使用chmod、chown或chgrp来更改它们的所有权或权限，这些更改将不会在重新启动时持续存在。

正因为如此，您有几种选择：

• 如果希望any用户能够只使用with特定程序的串行端口，可以向这些程序添加setuid uucp权限：

sudo chgrp uucp /some/where/Betaflight
sudo chmod g+s /some/where/Betaflight

• 如果希望<#>only某些用户能够使用串行端口，可以将这些用户添加到uucp组中：

sudo usermod -a -G uucp username

注意:在登录时将组成员分配给用户会话，因此如果用户已经登录--当进行此更改时，用户将需要注销并再次登录才能使更改生效。

• 如果您希望物理上在计算机(而不是远程登录(例如通过SSH)登录的用户)能够访问串行端口，则可以使用<#>only (如果使用)或systemd-logind模块为实际记录在控制台上的用户提供对设备节点的额外访问。

在较早的发行版中，这可能发生在会话期间将指定设备的所有权转移给用户并在会话结束后返回根，或者在登录时向本地登录的用户授予额外的组成员身份。现代实现倾向于为此目的在设备上使用访问控制列表(ACL)，因为对devtmpfs文件系统的ACL的支持已经成熟并变得无处不在。

使用systemd-logind，您可以通过为设备添加带有TAG+="seat"的udev规则，将设备分配给本地登录用户的控件。