| |||||||||||||
GNU Guix launchesGNU Guix launchesPosted Nov 27, 2012 1:35 UTC (Tue) by pspinler (subscriber, #2922)In reply to: GNU Guix launches by pboddie Parent article: GNU Guix launches
I'm not really arguing against systems administration policies, but it really baffles me that instead of entertaining and encouraging workable compromises and perhaps loosening the leash on captive users, organisations and developers would rather keep the leash as tight as possible even though history shows that the leash will break as a result. The issue is what management is willing to pay for. Sure, I can act as issue catcher and general hand holder, but then that takes a lot more of my time and the ratio of sysadmin to machine goes down. Management looks at that and says "what with all this automation, what's the problem?" Ergo, we took a pretty firm stance what we'd allow users to do on systems we administered, and management, by policy, required that production apps were on systems that were officially administered. Our compromise was that we still gave people sandboxes to play in where they could do anything to the system. We just took a very strict hands off to those sandboxes, and frowned mightily at using free play sandboxes for serious production work. -- Pat
(Log in to post comments)
GNU Guix launches Posted Nov 27, 2012 1:55 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
having worked at a company where things have devolved a couple of times into the "no restrictions" mode, you also end up finding that production reliability suffers drastically as well.
everybody thinks that they are above average in their ability to decide what to run, and this gets people in trouble.
Preventing them from installing packages doesn't solve all the problems by any means, but it does put people on notice that they aren't supposed to be doing that.
This sort of problem doesn't scale linearly with the number of users either. If you need one admin to help 5 people, 5 admins can't keep up with 25 people. It seems like they should be able to, but in practice they can't.
If you aren't willing to live with this sort of restriction on your work computer, find a job at another company, and be prepared to do so again in a few years as that company either grows and starts to implement restrictions, or goes the other direction.
Or become valuable enough that they make exceptions to their policies for you, but this takes having a track record of doing things right and not causing problems.
GNU Guix launches Posted Nov 27, 2012 15:35 UTC (Tue) by lambda (subscriber, #40735) [Link] If you don't allow people to install their own packages, they will just download, compile, and install them into their own directory (or run software written in scripting languages that don't require compilation), and now they have an outdated copy sitting in their home directory that's hard to update, and it's hard to find out that they're even doing this without looking. Why is it so threatening for users to be able to run their own software? They will do it anyhow; providing a framework for them to do so, while sharing dependencies, having a central database that the administrator can audit and tell people when they need to upgrade because of security issues (or forcibly upgrade them if need be) seems a lot preferable to having random pieces of software in who knows what state scattered around in home directories. Why is PHP so popular? It's certainly not its technical merits. One reason is that a user can just untar an application in their site directory and it will work; they don't have to ask a sysadmin to install it for them, request that their hosting provider install it and wait 3 months for it to actually happen, or the like. Nowadays environments like Rails are similar; there's a standard interface to the web server, and you can bundle all of your dependencies in with your application (other than the version of Ruby itself), so you can just stick a directory tree in an appropriate place on your server and it will just work. People install their own packages all the time in this manner. Why should this be restricted to web apps written in dodgy languages like PHP (or somewhat less dodgy environments like Ruby on Rails)?
GNU Guix launches Posted Nov 27, 2012 17:49 UTC (Tue) by davidescott (guest, #58580) [Link]
> If you don't allow people to install their own packages, they will just download, compile, and install them into their own directory (or run software written in scripting languages that don't require compilation), and now they have an outdated copy sitting in their home directory that's hard to update, and it's hard to find out that they're even doing this without looking.
In in ideal world: yes that would be better, but you are assuming that all software that might be installed through the package manager is regularly updated. What if the user installs something from a dead or dying project? The package might not be out of date (because no new release is forthcoming), but the sysadmin still needs to know enough about the program to know if it is a security risk.
Requiring explicit permission from root to install anything ensures that anyone who circumvents root's authority to approve/deny software installs is clearly doing something wrong. If its too urgent to bring through normal approval channels and they screw up the install and leave a security whole, then you can fire them. If they aren't confident that the tools they want to install are safe then they can do it the slow way with approved tools.
> Why is it so threatening for users to be able to run their own software? They will do it anyhow
Part of the problem is that you and I are talking about us. We know how to ./configure --prefix=...; make; make install; so WE can circumvent the policy, but WE are also fairly capable of recognizing good safe software from bad unsafe software, WE try to keep track of what we are doing, WE remove stuff we don't need, WE keep our software up to date, and WE appreciate having a tool to automate that process.
I'm not concerned about us, I'm concerned about THEM. The THEM who don't know a phishing scam from a real email, the THEM who think ftp is secure. I don't want THEM installing software. I want THEM to bring a use case forward, and a candidate application for installation so that people like us can guide them in finding the best supported way of accomplishing their goals.
GNU Guix launches Posted Nov 28, 2012 1:00 UTC (Wed) by hummassa (subscriber, #307) [Link]
It's a simple fallacy separating "we" (us?) from "them". We sometimes click on wrong links. We drive to the wrong neighborhood. One who has root can still veto some installed package or upgrade it and force the upgrade to the users' profiles. The facility here is that, instead of downloading a tarball and ./configuring make install, the user apt-gets (nixes, guixes) it from the repository where things are better controlled.
GNU Guix launches Posted Nov 28, 2012 13:47 UTC (Wed) by pboddie (subscriber, #50784) [Link]
You made my point much more concisely than I managed to do. :-)
Again, it's a matter of whether one can concede a degree of control in order to maintain a degree of supervision, or whether people will eventually feel obliged to break out and go to external entities for the goodies, leading to all sorts of recriminations afterwards (especially if something went wrong).
GNU Guix launches Posted Nov 27, 2012 23:54 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] If you don't allow people to install their own packages, they will just download, compile, and install them into their own directory (or run software written in scripting languages that don't require compilation), and now they have an outdated copy sitting in their home directory that's hard to update, and it's hard to find out that they're even doing this without looking. Assuming you have users who are capable of compiling from source or who have scripting languages installed on their machine. And that kind of user is probably capable enough that they ought to be given some kind of control over the software on their system, if for no other reason than that you can't stop them anyway. But those users are not the only kind that sysadmins need to be worried about. Put bluntly, some users really shouldn't be allowed to put software on their own machines. Not every user is capable and trustworthy enough to be given full control over their machine. Some systems contain sensitive information that must be protected from disclosure for legal or contractual reasons, and those machines really should be running only authorized, vetted software. Other machines may be provided in specific places for narrowly tailored purposes, like information kiosks, and should be running only software intended for that purpose. Real world admins need to be able to deal with those kinds of users and situations, and there should be tools that allow them to lock down machines to prevent unauthorized software from being run on them.
|
|||||||||||||