|
Description
I'd like to see a way for non-admin users to install programs via apt, into their home directory , so they don't need root access every time they even want tiny, succinct apps (like a fortune cookie program), and still have the convenience of a package manager
There would be no security risk or overall risk to system stability as apt would run with user privileges, so they would still not be able to do any worse then they normally could do.
Dangerous programs like VMware would still not be able to be fully installed (because kernel module installation requires root). And they would not be able to erase Xorg because they don't have write access to the Xorg directories.
But they could eliminate their reliance on tar.gz's from websites, and install programs such as vdrift or open office, using the standard package managers, without requiring root intervention.
A policy could be set in a config files to determine if local users should be able to use apt with local user permissions. The code for this is easy! That way you can still stop them using apt if you wish :D
PROS
1) Untrusted noobies can install or mess around in the full APT repo without ANY risk of system damage.
2) I can hand grandma a ubuntu laptop, without sudo/root access, allow her to install programs, without risk or giving her root.
3) This could technically be implemented now, with only a few changes to synaptic or adept. Apt is already ready
4) This is a way for users to step up to more advanced package managers, without screwing up the system.
CONS
1.1) A bit more hdd space usage. But people should be using quota's anyway to protect against this in most environments.
Tags:
(none)
Attachments
No attachments.
Duplicates
Comments
|
tomaszx wrote on the 11 Apr 08 at 08:56
| |
like name: "apt-get-local" i think that could be cool
|
|
probono wrote on the 11 Apr 08 at 13:26
| |
You might be interested in klik.atekon.de and klikclient.googlecode.com
|
|
Calimo wrote on the 12 Apr 08 at 11:32
|
I was about to post a new idea about this.
I think this is even more important now that "simple" users can face a plugin (in Firefox) or codec (in Totem) installation window in their regular use. The need for a root password for installing such a package is really a plague, and it should be allowed to install in /home, even for my mother, just clicking .
I didn't know that apt was already able to do it.
|
|
peterjs wrote on the 13 Apr 08 at 09:17
|
@Calimo
You're argument actually hurts this idea more than it helps it as your use case underscores the disk wastage and security problems this idea presents. Any libraries that can be shared (ie codecs or plugins), but aren't (because of static linking, or appearing in non-universal locations (as this idea suggests)), waste disk space by having multiple copies around, it may only be a few hundred Kb, but there's a prefectly good solution so there's no excuse for the waste no matter how small. The other problem with having multiple copies of shared libraries is inconsistent security updates, if you've got libfoo-1.1 in multiple places, and exploit is found in that version and libfoo-1.2 is released, you have to update every copy, miss one and you're still vulnerable, a centrally shared library by definition can't have this problem, because there's only one copy, so you never have to ask "Did I really get them all?"
Installing things in your home dir is all well and good for monolithic stuff that won't (and can't) be shared in any way, shape, or form. Encouraging users to install libraries in their home directory is a bad idea and encourages sloppy practices.
|
|
Auzy wrote on the 14 Apr 08 at 05:07
|
Peterjs, you may be right.. But:
1) Without it, you are forcing people to hand over sudo access to people who can screw up their systems with it.
I'd rather give newbies ubuntu without sudo rights, and let them still install stuff. No one would want a computer they don't have access over.
Thats why Palladium is a massive failure. People don't want to accept that Microsoft controls them.
2) You could always make security updates on user accounts compulsary.
3) They can already install programs using tar.gz. We shouldn't inconveniance users installations. Instead, we should be encouraging people to set up policies so they CANNOT install programs at all.
Otherwise, its very half-arsed security. Because you aren't preventing them installing programs, you are just purposely annoying those that need to.
Thats what i feel anyway. You either go the full hog with security (don't allow users to run executable code at all in their home directory), or its a pointless security measure
|
|
nedu wrote on the 15 Apr 08 at 20:32
|
This is a superficially attractive idea.
But --BUT-- it doesn't take into account the reality of the way applications are configured and built.
Pick some of your favorite apps. Download the source. Untar it. Run ./configure.
Now go look inside the Makefile at the directory locations that you just configured.
If you go ahead and run "make", but not "make install", will the executable run directly out of the build directory? Maybe. Maybe not. It depends.
Does your app look for stuff in the configured --sysconfdir, --localstatedir, or --datadir?
All in all, you've got a superficially attractive idea here. But it probably ends up making a lot more sense for users without root privileges who want to run their own apps to build those apps from source.
|
|
steve196 wrote on the 18 Apr 08 at 06:54
|
I don't get the "multiple copies of libraries" problem. You only need read access to libraries, and any user (unless explicitly configured otherwise) has that, if they are installed centrally.
Of course this does not always work, but most apps should support it. If one doesn't, uninstall it, bad luck.
Building from source is extremely tedious because of source dependencies.
|
|
Frederik Eaton wrote on the 20 May 08 at 19:00
|
Local, non-root package installation is a feature that I've been wishing for as well, for some time. It seems that it is not supported by any major package manager (except for language-specific ones like CPAN). When one searches for this feature online, one comes across many threads where the initial question is followed by off-topic responses such as "use sudo" or "that would be a security problem" or "are you crazy you are going to use too much disk space". The fact is that there are a vast number of situations where a local install would be very useful - testing packages, sharing systems with users who are not trusted with root access, having multiple incompatible versions of software installed in different "sandboxes". When I worked as a developer, I came across many such situations. In fact, some of my colleagues were busy using and developing package management software which seemed to exist just for this purpose (http://wigwam-framework.org/doc/overview.html).
I would strongly encourage people to avoid trying to argue that the requested feature is not useful, or that the need for it is not valid. If you don't want to use it, fine. But local installation would be a godsend to vast numbers of people. It is not a security issue, because what it entails can already be accomplished by compiling from source. It is not a matter of disk space, because compiling from source tends to use much more space than binary-only installation (and if you want to restrict disk usage, you can impose quotas). But these concerns are all moot, anyway. The purpose of software is to enable people to do things more efficiently, not to nanny them. If Auzy and others would find the feature useful, that is a reason to develop the feature. If some system administrator fears that his users would abuse the feature, he can easily ask his users not to use it on his system. That is certainly the best solution - that way only his own unfortunate users are affected, rather than the entire Ubuntu community.
In my mind, lack of support for local installation is the greatest misfeature of Debian-like package management systems. The question is not whether this feature should be implemented, but how hard it would be to implement. The answer may well be "too hard", but let's stay on topic.
|
|
Auzy wrote on the 21 May 08 at 02:12
|
Nedu. Yes, you are somewhat right, but nobody said my idea would be easy. If you look back to Xfree86 days, it was 1 man that made Linux what it was today, and a viable competitor to OSX (Keith Packard). Keith developed the Xcomposite extension for X11 (against others, and it wouldn't have been a trivial task). He didn't back down.
And when Xfree86 rejected it, he told them to go stuff it, and he forked the code into Xorg knowing it wouldn't be easy, but because of him, Linux is looking beautiful these days.
We have to stop voting down ideas just because they seem hard. Keith packard proved that a bit of hard work goes a very long way (if he gave up, and let Xfree get the best of him, we NEVER would have gotten XComposite, so Compiz would have never existed).
By developing this, we are also making a portable version of Apt that can run on even RPM based OS's easily.
And in the meantime, we are making it possible for anyone, even advanced users to simply play with Apt in their installation, and try out different packages without any risk of system damage.
And it also paves the way for many other new applications too.
And this also opens up the possibility, of making it possible for self contained Linux CD's to contain APT on them, and install themselves using APT, whilst also being able to be upgraded by Apt the normal way. So it would be a strong selling point against RPM's
|
|
probono wrote on the 31 May 08 at 12:47
| |
Well said, Auzy.
|
|
andruk wrote on the 6 Jul 08 at 08:11
|
The only problem I foresee is when users install an app, say Foo to their home, and then the admin installs Foo system-wide. It could get confusing as to which Foo is which, although this is easily remedied with labeling user-specific apps with stuff like "Foo - local".
Auzy, as is normal, has said everything else I wanted to say (and more).
+1
|
|
Auzy wrote on the 6 Jul 08 at 08:55
| |
This problem could also be overcome by correct environmental variables (ie PATH=/bin:~/programs/bin), which would search the system-wide bin before the users one.
|
|
elie wrote on the 22 Jul 08 at 06:26
| |
That would work. Also, when installing the system-wide version, there could be an option to remove any versions on user's homes (not destroying any of their files of course).
|
|
elie wrote on the 22 Jul 08 at 06:27
| |
* not destroying any of their personal data of course
|
|
g wrote on the 17 Aug 08 at 20:36
|
This is an important capability. Many large organizations impose barriers that make it difficult to install or update
end-user applications. IT support is responsible for admin and operations, including security patches, but end-user applications require a security review (paid by the end user) and vetting before they can be installed. A user may need access to more than one version of a package for testing. Disk space is typically not a concern -- disk is cheap and data for real projects is often many times larger than the software used to process it. There are several ways to use RPM packaging to install as an ordinary user. The OpenPKG project supports install without root privileges (and uses RPM). discusses installing vendor packages without privileges -- the main difficulty is that the user's private database has to be informed of prerequisites (e.g., by installing dummy packages).
What is needed:
1. tools to create a user database and synchronize it with
the system database. For RPM this is currently ad-hoc.
2. relocation options to edit the paths in a package. RPM
has this.
3. user-friendly means to identify packages that can't be used without system privileges (e.g., they install daemons).
RPM lacks this.
There are good tools to manage changes to the PATH and other environment settings to support use of packages
from a user configured location. I use the environment
modules package because I am familiar with from SGI IRIX64.
|
Post your comment
|
