[cl-debian] Bug#329347: common-lisp-controller: checking of permissions of the output directory
Package: common-lisp-controller Version: 4.18 Severity: minor Well AFAIFK is the standard policy for adding new users to the system as follows. - the user is created - a groups is created also so if I do a adduser foobar a group foobar will generated to If that is true then the following check should probably be changed (file post-sysdef-install.lisp) (unless (= 0 (logand mode #o022)) should be (unless (= 0 (logand mode #o002)) or one has to check - if the user has it's own group whether the permissions are ok then. With best regards Friedrich -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages common-lisp-controller depends on: ii bash 3.0-14 The GNU Bourne Again SHell ii cl-asdf 1.86-2 Another System Definition Facility ii debconf [debconf-2.0] 1.4.48 Debian configuration management sy ii debianutils 2.13.2 Miscellaneous utilities specific t ii perl 5.8.7-4 Larry Wall's Practical Extraction ii realpath 1.9.20 Return the canonicalized absolute common-lisp-controller recommends no packages. -- debconf information: * common-lisp-controller/long-site-name: * common-lisp-controller/short-site-name: flarge
Hello! On Wed 21 Sep 2005 11:23 +0200, Friedrich Dominicus wrote:
Well AFAIFK is the standard policy for adding new users to the system as follows. - the user is created - a groups is created also
so if I do a adduser foobar a group foobar will generated to
AFAIK the group creation is true only if (/etc/adduser.conf): ===== # The USERGROUPS variable can be either "yes" or "no". If "yes" each # created user will be given their own group to use as a default, and # their home directories will be g+s. If "no", each created user will # be placed in the group whose gid is USERS_GID (see below). USERGROUPS=yes =====
or one has to check - if the user has it's own group
This should be simple assuming that /etc/adduser.conf is set the first time and never changed (which could be not true). Just my 0.02EUR... Thx, bye, Gismo / Luca
Yet another reason why the only sensible thing for a per-user cache is to use ~/.cache: it is automatically safe with respect to whichever policy is defined by the administrator and/or user for access rights, disk quotas, etc, with no race condition to check for. The only possible downside is having to walk /etc/passwd to locate all the places where to purge the cache, if you wish to do such thing.
ii realpath 1.9.20 Return the canonicalized PS: Oh, instead of using realpath, could we be using readlink -f ? It's part of the GNU coreutils, so that's one less bizarre package to depend upon.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If six billion people have both more food and more forest than their three billion parents did; if the prices of copper, wheat and natural gas are going down, not up; if there are 20 times more carcinogens in three cups of organic coffee than in daily dietary exposure to the worst pesticide both before and after the DDT ban; if renewable resources such as whales are more easily exhausted than non-renewables such as coal; if lower infant mortality leads to falling populations, not rising ones, then perhaps we need to think differently about what sustainability means. Perhaps the most sustainable thing we can do is develop new technology, increase trade and spread affluence. -- Matt Ridley
On 21.09.05, Faré wrote: Hi Faré,
The only possible downside is having to walk /etc/passwd to locate all the places where to purge the cache, if you wish to do such thing.
No, it is the plain and true evil for package maintainer scripts to delete or modify files in users' home directories. It's the user's personal space and you never know what he uses ~/.cache for. The system should never modify the home directory and I do not know of one single package that does. René
A lot of packages install stuff in the user directory. Mozilla, Gimp, OpenOffice, KDE, GNOME, etc., will all create their own directories under ~/.<foo> and install a shitload of crap. Sometimes, their offer to upgrade from a previous version, and optionally offer to delete cruft from previous versions. Modifying users' directories is something done casually. The only problem is when it's done in unexpected, undocumented and/or unpredictable ways. Creating a well-defined ~/.cache/ hierarchy for such things as erasable caches is a generally good idea, and we should encourage more packages rather than less to do use it. I'm sure you can also invent a configuration file for users to specify their preferences regarding automatic administration of his home. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do. -- Henry Ford On 9/21/05, René van Bevern <rvb@progn.org> wrote:
On 21.09.05, Faré wrote:
Hi Faré,
The only possible downside is having to walk /etc/passwd to locate all the places where to purge the cache, if you wish to do such thing.
No, it is the plain and true evil for package maintainer scripts to delete or modify files in users' home directories. It's the user's personal space and you never know what he uses ~/.cache for. The system should never modify the home directory and I do not know of one single package that does.
René
On 21.09.05, Faré wrote:
On 9/21/05, René van Bevern <rvb@progn.org> wrote:
On 21.09.05, Faré wrote:
Hi Faré,
The only possible downside is having to walk /etc/passwd to locate all the places where to purge the cache, if you wish to do such thing.
No, it is the plain and true evil for package maintainer scripts to delete or modify files in users' home directories. It's the user's personal space and you never know what he uses ~/.cache for. The system should never modify the home directory and I do not know of one single package that does.
Hi Faré,
A lot of packages install stuff in the user directory.
I doubt that any package does this.
Mozilla, Gimp, OpenOffice, KDE, GNOME, etc., will all create their own directories under ~/.<foo> and install a shitload of crap.
But this is done by the applications themselves and not by packages or their maintainer scripts -- and not for all home directories they can find. It's up to each user if that happens or not.
Sometimes, their offer to upgrade from a previous version, and optionally offer to delete cruft from previous versions.
That is fine. The application themselves can offer transitions from previous versions. But a maintainer script in a package that runs through the home directory of all users to delete files is not fine. The applications *offer* it, it's in the user's hands what happens finally. This would not be the case if a maintainer script traversed all home directories to delete caches.
Modifying users' directories is something done casually.
Not by packages or their scripts and not without user interaction. It's dangerous. René
On Wednesday 21 September 2005 15:49, René van Bevern wrote:
A lot of packages install stuff in the user directory.
I doubt that any package does this.
1/pvaneynd@sharrow:~ :( $ grep '^/home/' /var/lib/dpkg/info/*.list 1/pvaneynd@sharrow:~ :( $ None on my system.
Not by packages or their scripts and not without user interaction. It's dangerous.
After thinking it over I do agree with this. I will resist any change to move the cache directory over to a location beneath /home unless there is a change in debian policy on this. I am willing to provide hooks to permit a user to move the fasls to a location of choice. I fear I did not have time yet to investigate cl-launch but I'll try to make some time for it. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
participants (5)
-
Faré -
Friedrich Dominicus -
Luca Capello -
Peter Van Eynde -
René van Bevern