3 ms·

You're contradicting yourself in your first and second paragraph... Those proper package managers still rely on the packager doing things correctly - just as i

You're contradicting yourself in your first and second paragraph... Those proper package managers still rely on the packager doing things correctly - just as it would creating a windows .msi. There's plenty of linux packages that creates files during operation in their designated /var/log/xxx /var/db/xxx /etc/xxx /home/xxx/ directories that you're not able to query using the package manager.

Already__Taken 8y ago
Isn't the parallel to UAC a properly configure SELinux? I thought that was the component that lets process rwx from certain locations? I guess a full comparison may be including applocker too. Not to hot on linux management options I just install the thing over and over.
laumars 8y ago
> You're contradicting yourself in your first and second paragraph... Those two paragraphs are talking about different OSs. 1st paragraph is talking about Windows, 2nd paragraph is talking about non-Windows systems with first-class package managers such as ArchLinux, Debian, CentOS, FreeBSD, etc. > Those proper package managers still rely on the packager doing things correctly Sure, but the point is you can query what the package manager has done. > There's plenty of linux packages that creates files during operation in their designated /var/log/xxx /var/db/xxx /etc/xxx /home/xxx/ directories that you're not able to query using the package manager. That's half true. You can query that /var/db/xxx and /var/log/xxx has been created by the package manager and often the directories (and their contents) will be owned by the user which the daemon runs under. However I do agree with the point regarding your $HOME directory and actually made that point myself: > Of course you still have the problem of the software writing files during its operation but that should be limited to $HOME (on POSIX systems) or any path that is writable by the owner / group of the user that application runs as (which should be limited even if it’s a system service). As an aside, you can also query what files a particular application has open. In fact there are a few ways to do this from querying the /proc/$PID directory through to tools like `lsof`.
- noselasd 8y ago
  I have plenty of files in /var/lib/ that are not owned by any package, same in /var/log/ , /var/cache/ , /etc/sysconfig/ and other directories - their parent directory is owned by a different package than the ones creating these files. I'm not arguing that a decent package manager is a better than none - but they are solving all issues you claim they do. Pretty much all OSs, including windows, have ways to view which processes has a file open
  - laumars 8y ago
    > I have plenty of files in /var/lib/ that are not owned by any package, same in /var/log/ , /var/cache/ , /etc/sysconfig/ and other directories - their parent directory is owned by a different package than the ones creating these files. Got any examples of that? You'd expect only docker to write to /var/lib/docker, mysql to write to /var/lib/mysql. etc. Not discounted that I've overlooked something but a quick look in my /var/lib and it's easy to see what is managed by what. So I'm curious what instances you have of a package manager creating a directory and then a completely unrelated daemon writing to that directory. > I'm not arguing that a decent package manager is a better than none - but they are solving all issues you claim they do. I'm not claiming they solve all the problems - in fact I literally identified a few problems they don't solve! Plus even those points I identified aside, there will always be edge cases for thing that package manager should have solved but failed to do so. Perhaps we should turn this discussion on it's head and discuss better ways to solve the problems people are describing? What would your solution be? Or are you ostensibly agreeing with my points but being contrary just for the sake of playing devils advocate? > Pretty much all OSs, including windows, have ways to view which processes has a file open Isn't that literally what I just said? (plus I gave a few examples too).
    - plopz 8y ago
      > Got any examples of that? Not the person you were talking to, but looking at certbot, it puts files into /lib/systemd/system/ and /etc/cron.d/ with root:root.

Already__Taken 8y ago

Isn't the parallel to UAC a properly configure SELinux? I thought that was the component that lets process rwx from certain locations? I guess a full comparison may be including applocker too. Not to hot on linux management options I just install the thing over and over.

laumars 8y ago

> You're contradicting yourself in your first and second paragraph... Those two paragraphs are talking about different OSs. 1st paragraph is talking about Windows, 2nd paragraph is talking about non-Windows systems with first-class package managers such as ArchLinux, Debian, CentOS, FreeBSD, etc. > Those proper package managers still rely on the packager doing things correctly Sure, but the point is you can query what the package manager has done. > There's plenty of linux packages that creates files during operation in their designated /var/log/xxx /var/db/xxx /etc/xxx /home/xxx/ directories that you're not able to query using the package manager. That's half true. You can query that /var/db/xxx and /var/log/xxx has been created by the package manager and often the directories (and their contents) will be owned by the user which the daemon runs under. However I do agree with the point regarding your $HOME directory and actually made that point myself: > Of course you still have the problem of the software writing files during its operation but that should be limited to $HOME (on POSIX systems) or any path that is writable by the owner / group of the user that application runs as (which should be limited even if it’s a system service). As an aside, you can also query what files a particular application has open. In fact there are a few ways to do this from querying the /proc/$PID directory through to tools like `lsof`.

noselasd 8y ago
I have plenty of files in /var/lib/ that are not owned by any package, same in /var/log/ , /var/cache/ , /etc/sysconfig/ and other directories - their parent directory is owned by a different package than the ones creating these files. I'm not arguing that a decent package manager is a better than none - but they are solving all issues you claim they do. Pretty much all OSs, including windows, have ways to view which processes has a file open
- laumars 8y ago
  > I have plenty of files in /var/lib/ that are not owned by any package, same in /var/log/ , /var/cache/ , /etc/sysconfig/ and other directories - their parent directory is owned by a different package than the ones creating these files. Got any examples of that? You'd expect only docker to write to /var/lib/docker, mysql to write to /var/lib/mysql. etc. Not discounted that I've overlooked something but a quick look in my /var/lib and it's easy to see what is managed by what. So I'm curious what instances you have of a package manager creating a directory and then a completely unrelated daemon writing to that directory. > I'm not arguing that a decent package manager is a better than none - but they are solving all issues you claim they do. I'm not claiming they solve all the problems - in fact I literally identified a few problems they don't solve! Plus even those points I identified aside, there will always be edge cases for thing that package manager should have solved but failed to do so. Perhaps we should turn this discussion on it's head and discuss better ways to solve the problems people are describing? What would your solution be? Or are you ostensibly agreeing with my points but being contrary just for the sake of playing devils advocate? > Pretty much all OSs, including windows, have ways to view which processes has a file open Isn't that literally what I just said? (plus I gave a few examples too).
  - plopz 8y ago
    > Got any examples of that? Not the person you were talking to, but looking at certbot, it puts files into /lib/systemd/system/ and /etc/cron.d/ with root:root.