3 ms·

Isn't the separation of programs into sbin to prevent users without system admin permissions having even read only access to certain programs? Is that not relev

Isn't the separation of programs into sbin to prevent users without system admin permissions having even read only access to certain programs? Is that not relevant now?

stryan 3y ago
Outside of what the article itself says, even while I was managing large multi-user Linux installs that wasn't really a concern we had. At this point the benefits and concerns are minimal.
layer8 3y ago
Read the linked change proposal.
halJordan 3y ago
Yep, it's not relevant. If you click through to the change proposal, you will see their reasoning.
- nuc1e0n 3y ago
  Meh. I'm not bothered whether they're merged or not then. All these folders are administered by rpm anyhow.
  - cycleslow 3y ago
    Uhhhh, more than rpm exists. I fail to see a problem that is solved by merging them. I guess some fresh project manager with nothing to do believes they found some low-hanging fruit to get their name on something. ¯\_(ツ)_/¯ It's a waste of time to reinvent this wheel. It will probably make things worse. Many of these ideas come from folks who started with something other than a *nix and are trying to make things feel more like home rather than understand why things are the way they are.
brirec 3y ago
I’ve never seen a distro that didn’t grant read permission to everyone for /sbin and /usr/sbin. In any event, it doesn’t really make sense to me to deny read access for any executables, so long as you don’t also deny read access to Python or a C compiler. Really, if permission mode bits are the only thing preventing damage from such tools your vulnerability is not within your path or mode bits.
Phrodo_00 3y ago
Not really, that can still be done without permissions. You WOULD be able to stop them from knowing the files are there if you remove read permissions to others, but I haven't seen this done. The main advantage I see of having them separate is that you can remove sbin from user's $PATH to avoid confusion.

Isn't the separation of programs into sbin to prevent users without system admin permissions having even read only access to certain programs? Is that not relevant now?

stryan 3y ago

Outside of what the article itself says, even while I was managing large multi-user Linux installs that wasn't really a concern we had. At this point the benefits and concerns are minimal.

layer8 3y ago

Read the linked change proposal.

halJordan 3y ago

Yep, it's not relevant. If you click through to the change proposal, you will see their reasoning.

nuc1e0n 3y ago
Meh. I'm not bothered whether they're merged or not then. All these folders are administered by rpm anyhow.
- cycleslow 3y ago
  Uhhhh, more than rpm exists. I fail to see a problem that is solved by merging them. I guess some fresh project manager with nothing to do believes they found some low-hanging fruit to get their name on something. ¯\_(ツ)_/¯ It's a waste of time to reinvent this wheel. It will probably make things worse. Many of these ideas come from folks who started with something other than a *nix and are trying to make things feel more like home rather than understand why things are the way they are.

brirec 3y ago

I’ve never seen a distro that didn’t grant read permission to everyone for /sbin and /usr/sbin. In any event, it doesn’t really make sense to me to deny read access for any executables, so long as you don’t also deny read access to Python or a C compiler. Really, if permission mode bits are the only thing preventing damage from such tools your vulnerability is not within your path or mode bits.

Phrodo_00 3y ago

Not really, that can still be done without permissions. You WOULD be able to stop them from knowing the files are there if you remove read permissions to others, but I haven't seen this done. The main advantage I see of having them separate is that you can remove sbin from user's $PATH to avoid confusion.