6 ms·

5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.

by nomel 9mo ago

cyberax 9mo ago
They're already reported. And ignored. Have you _seen_ the systemd issue backlog? The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored. The remote FS detection also came up multiple times, and the maintainers don't care.
- nomel 9mo ago
  > and the maintainers don't care. I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report. This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.
  - cyberax 9mo ago
    The problem here is more fundamental. Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because." I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy. I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local"). I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.
    - dTal 9mo ago
      This is one example of a more general complaint about systemd and related projects: they force policy, rather than simply providing mechanisms. I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this? It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing. Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo. I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.
  - simoncion 9mo ago
    > I think better proof of this would be a rejected PR rather than a neglected bug report. I understand the sentiment you're expressing here, and it's often a reasonable one. However, when every sharp edge case I've encountered with SystemD (both professionally and personally) ends either in a open Github Issue whose discussion from the project maintainers ends up being "Wow. That's tricky. I'm not sure whether or not that behavior is correct. Maybe we should do something about this or document this so other folks know about it." (and then nothing happens, not even the documentation) or a closed Github Issue with "Sorry, your usecase is <strike>inconvenient to implement</strike> unsupported. E_NOTABUG", expecting PRs is expecting way too much.
    - its_magic 9mo ago
      I've long been in the habit of reading accounts like yours, understanding the truth and wisdom that's being expressed, then noping the fuck out of the tech/product/situation in question. It has saved me a lot of trouble over the years. Even as others are completely mystified. Some people just like abuse, I guess. "Sweet dreams are made of this..."
- jdub 9mo ago
  OK, think it through... How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? Consider that the network endpoint might be localhost, a netlink/unix/other socket, or, say, an IP address of the virtual host (practically guaranteed to be there and not truly "remote"). systemd has .mount units which are way more configurable than /etc/fstab lines, so they'd let you, as the administrator, describe the network dependency for that specific instance. But what if all we have is the filesystem type (e.g. if someone used mount or /etc/fstab)? Linux doesn't tell us that the filesystem type is a network filesystem. Linux doesn't tell us that the specific mount request for that filesystem type will depend on the "network". Linux doesn't tell us that the specific mount request for that filesystem type will require true network connectivity beyond the machine itself. So, before/without investing in a long-winded and potentially controversial improvement to Linux, we're stuck with heuristics. And systemd's chosen heuristic is pretty reasonable - match against a list of filesystem types that probably require network connectivity. If you think that's stupid, how would you solve it?
  - simoncion 9mo ago
    > How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? The '_netdev' option works a treat on sane systems. From mount(8): _netdev The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system). It should work on SystemD and is documented to in systemd.mount Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount. but -surprise surprise- it doesn't reliably work as documented because SystemD is full of accidental complexity.
    - jdub 9mo ago
      Sure, and systemd would translate that directly into a dependency on network startup, which is precisely equivalent to the approach I mentioned that depends on operator knowledge. It's configuration, not "just works" inference.

5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.

by nomel 9mo ago

5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.

They're already reported. And ignored. Have you _seen_ the systemd issue backlog? The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored. The remote FS detection also came up multiple times, and the maintainers don't care.

nomel 9mo ago
> and the maintainers don't care. I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report. This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.
- cyberax 9mo ago
  The problem here is more fundamental. Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because." I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy. I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local"). I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.
  - dTal 9mo ago
    This is one example of a more general complaint about systemd and related projects: they force policy, rather than simply providing mechanisms. I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this? It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing. Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo. I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.
- simoncion 9mo ago
  > I think better proof of this would be a rejected PR rather than a neglected bug report. I understand the sentiment you're expressing here, and it's often a reasonable one. However, when every sharp edge case I've encountered with SystemD (both professionally and personally) ends either in a open Github Issue whose discussion from the project maintainers ends up being "Wow. That's tricky. I'm not sure whether or not that behavior is correct. Maybe we should do something about this or document this so other folks know about it." (and then nothing happens, not even the documentation) or a closed Github Issue with "Sorry, your usecase is <strike>inconvenient to implement</strike> unsupported. E_NOTABUG", expecting PRs is expecting way too much.
  - its_magic 9mo ago
    I've long been in the habit of reading accounts like yours, understanding the truth and wisdom that's being expressed, then noping the fuck out of the tech/product/situation in question. It has saved me a lot of trouble over the years. Even as others are completely mystified. Some people just like abuse, I guess. "Sweet dreams are made of this..."
jdub 9mo ago
OK, think it through... How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? Consider that the network endpoint might be localhost, a netlink/unix/other socket, or, say, an IP address of the virtual host (practically guaranteed to be there and not truly "remote"). systemd has .mount units which are way more configurable than /etc/fstab lines, so they'd let you, as the administrator, describe the network dependency for that specific instance. But what if all we have is the filesystem type (e.g. if someone used mount or /etc/fstab)? Linux doesn't tell us that the filesystem type is a network filesystem. Linux doesn't tell us that the specific mount request for that filesystem type will depend on the "network". Linux doesn't tell us that the specific mount request for that filesystem type will require true network connectivity beyond the machine itself. So, before/without investing in a long-winded and potentially controversial improvement to Linux, we're stuck with heuristics. And systemd's chosen heuristic is pretty reasonable - match against a list of filesystem types that probably require network connectivity. If you think that's stupid, how would you solve it?
- simoncion 9mo ago
  > How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? The '_netdev' option works a treat on sane systems. From mount(8): _netdev The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system). It should work on SystemD and is documented to in systemd.mount Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount. but -surprise surprise- it doesn't reliably work as documented because SystemD is full of accidental complexity.
  - jdub 9mo ago
    Sure, and systemd would translate that directly into a dependency on network startup, which is precisely equivalent to the approach I mentioned that depends on operator knowledge. It's configuration, not "just works" inference.