On Thu, Jan 2, 2014 at 12:24 PM, Bob Proulx <b...@proulx.com> wrote: > [...] > For example if you install squirrelmail it will include > /usr/share/squirrelmail/**.php files in the package. Root owns those > files. This is good because that prevents any other account from > being able to modify those files. That is just long standing good > design.
Well, you know, I have been trying to work out a way to generate a user to own each application. Without breaking the ability to update, etc. There are people who want to combine /bin, /sbin, /usr/bin, and /usr/sbin. I want to go the opposite direction, to put each application in its own subdirectory under /app or something, and put links to the provided apps in /bin/<user>/bin or something, so that each user can have his own chrooted /bin with only the apps that user should be allowed to use. And I want to allocate an application-specific user to own each application. Maybe more than one. Separate from the user(s) allocated to run the daemons and servers for the application. To take advantage of such a setup, each application would need to supply a set of standard update routines, and update itself when directed to by the system, I suppose. Otherwise, admin users would have to sudo or su to root anyway, which I suppose is one of the reasons no one has been so, ehh, fanatical? about it yet. I wonder whether we could design a set of default update calls for such a system. It's a project to keep on the back burner, I suppose. >> It is a very bad idea to use the root user to do such mundane >> things. > > System administration is hardly mundane. It is often misunderstood > (as in this thread) but very important work. > [...] I think the point is that certain configuration files could well be owned by a special purpose user. Say I'm building a content-management system called "zerostone" and it provides a web-facing configuration mechanism. I'd set it up so that the user "admst0ne" owned the configuration files that could be accessed from the web, and the server that provides access to the configuration files would maybe run as admst0ne. The non-web-facing configuration files would be owned by "zishi", and all human users who are allowed to log in to a regular shell and edit the configuration files would be members of the "zishi" group, or be allowed to sudo to "zishi" by rules in the /etc/sudoers.d directory. Or something like that. Purely hypothetical, of course. -- Joel Rees Logic kills. How logical do you want to be? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iNy63YfReTiM-nJXMM32vvndLfAYHQZQcjn=tsq5ag...@mail.gmail.com
