| |||||||||||||
GNU Guix launchesGNU Guix launchesPosted Nov 26, 2012 19:32 UTC (Mon) by dlang (✭ supporter ✭, #313)In reply to: GNU Guix launches by pboddie Parent article: GNU Guix launches
I'll point you several layers up in this thread
In a construction company, just because everyone is carrying tools that would let them break into the Dynamite Storage locker doesn't mean that you should just give everyone the key (or not bother to lock it in the first place)
Similarly, just because it's possible for a knowledgable person to bypass the restrictions on installing software on a machine doesn't mean that yhere are no cases where such restrictions make sense.
As far as I'm concerned, per-user application installs really don't make much sense nowdays. Almost all systems are single-user, so there is only the one user to install the app for. The few cases that remain where there are multiple users on a single system image are all cases where it's probably a bad thing to have users installing software (especially given how easy it is to have separate system images with either virtual machines ot containers to isolate the users when you do want them to share hardware)
(Log in to post comments)
GNU Guix launches Posted Nov 26, 2012 19:52 UTC (Mon) by apoelstra (subscriber, #75205) [Link]
> As far as I'm concerned, per-user application installs really don't make much sense nowdays. Almost all systems are single-user, so there is only the one user to install the app for. The few cases that remain where there are multiple users on a single system image are all cases where it's probably a bad thing to have users installing software (especially given how easy it is to have separate system images with either virtual machines ot containers to isolate the users when you do want them to share hardware)
Even on a single-user system, there are many "users" like apache, ftp, sshd, dbus, etc. And these programs often have security as a high priority, and would not like libraries being switched out underneath them.
So it's nice to be able to install applications and libraries in my own home directory, even though I'm the only human user of the system, just to avoid upsetting the rest of the system.
GNU Guix launches Posted Nov 26, 2012 21:07 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
the "users" like Apache, ftp, sshd, dbus, etc had better not be installing software packages for themselves.
If you want to not have these different things depend on a common set of libraries, you still don't need per-user installable packages, you just have a distro do static linking of libraries instead of dynamic linking (or you use chroot sandboxes or containers)
GNU Guix launches Posted Nov 26, 2012 22:39 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
If you had perfect foresight that would be a fine answer. It's hard to 'go back' and change the way things are set up when you find you need something a little different today.
GNU Guix launches Posted Nov 27, 2012 13:15 UTC (Tue) by pboddie (subscriber, #50784) [Link]
Enough with the dynamite analogy: I never suggested that people should be able to "blow up" their systems with full root access. Indeed, it's precisely this attitude - that wanting to do only a little more than currently possible is somehow the same as "wanting it all" - that undermines any discussion on such matters and drives people towards exactly the social and institutional workarounds I already described.
It's interesting to hear the claim that most systems - presumably Unix-related ones - are now single-user systems. Even if that is the case, giving people the ability to customise that environment without having to nag the administrative staff all the time is surely beneficial. Indeed, what has often happened is that people on those traditionally single-user Windows systems have been able to more or less install what they want, with all the accompanying consequences, whereas everyone else has had to make do with what they're given.
If people could just apt-get a package and have it installed in their home directory, it wouldn't necessarily affect the other users at all. Of course they could fill up the disk with a complete installation of GNOME or whatever, but that's what quotas are for. (Although I now expect to be told that quotas are archaic and people virtualise entire systems to get the same effect for this as well. If so, Linus Torvalds and the GNU project maintainers should consider slashing away at the realms of apparently dead code that no-one seriously uses any more.)
GNU Guix launches Posted Nov 27, 2012 16:00 UTC (Tue) by davidescott (guest, #58580) [Link]
> I never suggested that people should be able to "blow up" their systems with full root access.
We are both coming at this from different perspectives, so your example is installing Inkscape, and mine is installing Apache/Ruby/Haskell/GCC
Inkscape is a reasonably safe application to install because in the end the application either works or doesn't and what matters is the produced SVG file which is either compliant or non-compliant. I would have no objections to anyone installing that for one off interactive use.
Installing a web-server or a full-fledged programming language raises more concerns because it introduces something that has to be maintained into the future.
The problem is that the acceptability of applications is defined by the individual policy of the firm. Somehow the package manager has to classify packages in a manner that is consistent with the policy articulated by the firm, allowing the firm to then blacklist/whitelist individual packages as needed.
The problems are:
b) How granular is the classification to be? Are packagers really going to want to classify applications at the level of detail required by administrators trying to implement policy? Do they even know what administrators consider important? Do they agree?
c) Can any classification scheme possibly match policy? Policy might have more to do with use in practice than capability. Consider your Inkscape example. I might allow the occasional usage of Inkscape to create SVGs, but want to prohibit the scripting of Inkscape through python to automate the creation of charts for publishing. If Inkscape is white listed and python is a system dependency it may be impossible to express policy in a whitelist/blacklist at the package level, and some more conservative firms will then look at that and decide to blacklist everything.
d) Is policy defined or is it fuzzy? The firm may not know what to allow because they cannot anticipate all the crazy ways people might use the software they install. If the firm could actually articulate their policy clearly enough to implement as package management rules then the approval process would be much faster and might eliminate the need to even have this feature.
GNU Guix launches Posted Nov 28, 2012 13:29 UTC (Wed) by pboddie (subscriber, #50784) [Link] First of all, thanks for keeping the discussion productive and informative. I think that one of the fundamental differences in perspective is related to the following remark: The problem is that the acceptability of applications is defined by the individual policy of the firm. Somehow the package manager has to classify packages in a manner that is consistent with the policy articulated by the firm, allowing the firm to then blacklist/whitelist individual packages as needed. Here, we're talking about more than one organisational role. One matter is what people can do on their workplace machines to do their work in the most convenient and productive way possible without disturbing others or doing bad things to the workplace's systems. Another matter is whether the techniques used are sustainable and documented so that other people in the workplace can follow what was done. In the case of Apache, surely the way to deal with the possibility of someone installing it is to make sure that any instance of it will never be seen from any other computer, which is probably a policy employed in organisations where "high ports" are regarded as completely untrusted. The tools already exist to contain unprivileged users, mostly because that was the motivation for having multi-user/privilege systems in the first place. So it seems to me that forbidding package installation - recalling that I only advocate installation under non-root privileges - is a very coarse way of controlling what users do, and the extent of that control will rely on the existing measures, anyway. (Forbidding the installation of Ruby doesn't stop people from writing "bad" programs unless you take the shell away from them as well.)
GNU Guix launches Posted Nov 28, 2012 17:13 UTC (Wed) by davidescott (guest, #58580) [Link]
I don't see how we are ever going to agree, because we see something like "running apache on a high port on an internal desktop for internal business purposes" differently.
You view it as developer Joe just wanting to be able to run the server for his own use, and it cannot possibly harm anyone so long as the corporate firewall works.
Management may see it as (a) something that others may come to rely upon and when Joe leaves for another firm someone else has to take over requiring that the code be brought up to the appropriate standards or (b) an internal application that leaks data across business lines and fails to integrate with the standard security policies managed by the firm.
Similarly with installing Inkscape, it could become something that is integrated into a process without approval, such that nobody knows how to manage it when the installer leaves, or could expose the firm to legal risk down the road (those automated charts Joe creates with inkscape are deemed to be deceptive according to Regulation 142.6(a) subsection (iv) paragraph 3.14 which requires that all bar charts have a width of at least 22px). I personally don't like this attitude, but after working in a regulated industry I recognize that it exists.
You are also implicitly suggesting that every machine on the internal network run a firewall that blocks incoming packets on high ports. How many companies actually do this, vs just having a firewall at gateway? It could be a lot of work for network admins to customize the firewall rules to the individuals machine.
I'd also be curious to know how a company like Google handles this kind of situation. Certainly their staff is skilled enough to be able to run personal web-servers, but at the same time someone with a misconfigured server could leak data across the google network.
--------------------------------------------------
A lot of this audit stuff is ridiculous, and I think there is a tacit recognition that it is absurd. Saying that an employee went off an did something on his own without approval makes it possible for the corporation to avoid liability, whereas if you all them to apt-get install something its much less clear that they were violating policy in doing so.
GNU Guix launches Posted Nov 28, 2012 19:59 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
I assume that there would be a way that administrators could disable per-user package installation if wanted. I don't see how the *existence* of the feature is a problem in and of itself. I'd certainly like to be able to install different versions of the boost packages into a local directory so that I don't have to touch Boost.Jam umpteen times to test against everything from 1.44 to the latest release. Or try out the newest shiny (especially with things like newer mesa where if it screws up, I still have a fallback to rely on). without having to upgrade an entire distro (or install an ancient one for older versions).
I would like to have 10 compiler versions installed so that I can test everything with one machine instead of needing 10 VMs of various versions of distros to get those versions and installing things by RPM is a whole lot more reliable than me trying to replicate what is installed in those systems manually.
GNU Guix launches Posted Nov 28, 2012 21:23 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
The issue is that the main case for why this feature is needed is a very close overlap with the cases where it is very questionable due to the reasons mentioned above.
As far as installing multiple compilers, go read Rob Landley's notes of the fun he has doing cross compiles, specifically all the work he has to do to beat gcc into using the right version of things. It sure doesn't look like it would be nearly as trivial as "install multiple copies of gcc in different directories"
If I had to do that, I'd use debbootstrap to create chroot sandboxes with different versions installed in each one. You don't even need containers, let alone VMs.
GNU Guix launches Posted Nov 29, 2012 14:23 UTC (Thu) by pboddie (subscriber, #50784) [Link]
I do actually use debootstrap with chroot sandboxes precisely to be able to manage multiple software environments. However, this only works reliably for genuine chroots and not fakechroots, at least if you want to sample other distribution versions (mostly because of system library incompatibilities), and it gets to the point where you also need a newer kernel version to run significantly newer distribution versions. At that point, I actually use User Mode Linux, but there are plenty of root privilege obstacles that would prevent me from having such a sandbox if I didn't have root access.
Setting up chroot sandboxes isn't really so lightweight, but I suppose it is at the lighter end of the virtualisation spectrum in the broadest sense of the term.
GNU Guix launches Posted Nov 29, 2012 17:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I don't want to install old RPMs as-is; that way does indeed lead down into its own dependency hell. I would like to recompile Fedora 14 RPMs for my current machine and still be able to install it somewhere.
GNU Guix launches Posted Nov 29, 2012 18:00 UTC (Thu) by pboddie (subscriber, #50784) [Link]
I don't do things with RPMs, but if I wanted to build a Debian package for my current distribution version, I guess I'd go through the usual dpkg-buildpackage route (or use pbuilder if I had root access) after tweaking the package metadata. Since I only ever back-port things (and not that often given that I may choose to run them in a chroot), I don't know how much work would actually be necessary to forward-port a package, but quite possibly not that much.
Installing the package is another matter, though. Without root access, I'd have to hope that my fakechroot sandbox is up to the task, but given that it would be the same distribution version, the chances of that are a bit higher than they otherwise might be. I suppose that febootstrap would be able to deliver the same experience for Fedora, potentially not even needing fakechroot to do an initial bootstrap.
GNU Guix launches Posted Nov 29, 2012 17:20 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Hmm…installing a different GCC in macports looks like it just dumped it all in its own subdirectory. I'm not so interested in cross compilers, just different versions of various compilers.
I don't know why GCC would have problems with it unless you used the same $PREFIX for all of them. It's not like GCC would know to look anywhere other than its installation tree and possibly the system. Usually I use $HOME/misc/root/$name-$version as the prefix so that removing one is an rm -rf without having to rely on whatever (usually broken) uninstall mechanisms the project uses. LLVM is certainly happy being installed to $HOME/misc/root/llvm-3.2svn without being confused by the system version.
GNU Guix launches Posted Nov 29, 2012 17:06 UTC (Thu) by davidescott (guest, #58580) [Link]
We aren't objecting to the existence of the feature. If someone wants to implement it that is their right. What we are questioning is the marketability of the feature. It was initially described as a killer feature of Nix, but in my mind Virtualization looks a lot better for a number of different potential use cases. Other than shared hosting (which I don't have a particularly high opinion of to begin with). I'm genuinely curious what use case makes this the killer feature that really sells Nix/Guix.
|
|||||||||||||