Re: Bits from the release team: the plans for etch
On Fri, Nov 04, 2005 at 11:01:20AM -0800, Philippe Troin wrote: Although I agree with the above on principle, how do you manage membership to the floppy, audio, video, etc groups? pam_group for example. If you want to let some users access the devices even if they are not logged in at the console, then it is better to use sudo some helper scripts (so syslog will contain who did what). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Gabor Gombas [EMAIL PROTECTED] writes: On Fri, Nov 04, 2005 at 11:01:20AM -0800, Philippe Troin wrote: Although I agree with the above on principle, how do you manage membership to the floppy, audio, video, etc groups? pam_group for example. pam_group would work for floppy, audio and video. But it's insecure. And it does not solve the problem for group membership like Debian-exim. If you want to let some users access the devices even if they are not logged in at the console, then it is better to use sudo some helper scripts (so syslog will contain who did what). Yes, it can be done. But it's also impractical. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Gabor Gombas [EMAIL PROTECTED] writes: On Sat, Oct 29, 2005 at 10:21:13PM -0700, Philippe Troin wrote: An other issue that always annoyed me is that assuming a NIS server and a NIS client which both install say exim. I want to give some users membership in the group Debian-exim. I can't easily. The UID picked by Debian-exim is not going to be the same for the NIS server and all the NIS clients, so I cannot get it propagated by NIS. And I don't want to have to maintain the group membership on all the clients. That is a local administration decision. You should have a clear policy wether you'll be allowing system groups in NIS _before_ creating the NIS domain. If you do, you should have a plan _before_ creating the NIS domain about how you will deal with the inevitable conflicts. When I last administered a complex distributed environment (we used first NIS+ then LDAP, but that's not important), we had a policy that local software should never use user/group IDs coming from NIS+/LDAP, and software installed on shared filesystems should never use user/group IDs _not_ coming from NIS+/LDAP. Mixing local and remote IDs in group membership was forbidden as well. That worked quite well. Although I agree with the above on principle, how do you manage membership to the floppy, audio, video, etc groups? Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Sat, Oct 29, 2005 at 12:46:47AM +0200, Rolf Kutz wrote: The admin should know whether he messed with the account and if he did just remove the package instead of purging it. It's not like packages get purged by themself. Messing with the _account_ is not the same as messing with config files. Give me a dpkg option that removes all config files but still leaves the account alone, and I'll be happy. You can at least see _some_ of the config files that will be removed using dpkg -L but there is no way to get a list of users/groups that will be removed by --purge. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Sat, Oct 29, 2005 at 10:21:13PM -0700, Philippe Troin wrote: An other issue that always annoyed me is that assuming a NIS server and a NIS client which both install say exim. I want to give some users membership in the group Debian-exim. I can't easily. The UID picked by Debian-exim is not going to be the same for the NIS server and all the NIS clients, so I cannot get it propagated by NIS. And I don't want to have to maintain the group membership on all the clients. That is a local administration decision. You should have a clear policy wether you'll be allowing system groups in NIS _before_ creating the NIS domain. If you do, you should have a plan _before_ creating the NIS domain about how you will deal with the inevitable conflicts. When I last administered a complex distributed environment (we used first NIS+ then LDAP, but that's not important), we had a policy that local software should never use user/group IDs coming from NIS+/LDAP, and software installed on shared filesystems should never use user/group IDs _not_ coming from NIS+/LDAP. Mixing local and remote IDs in group membership was forbidden as well. That worked quite well. Yet some packages do not deal very well with that solution: some are confused by some user or group that they cannot modify with usermod or groupmod. Others are confused when removing the user or group (userdel and groupdel failing to remove a NIS entry). Well, administering a distributed environment is more complicated than administering a single machine and you should be prepared for this kind of problems. As for Debian, it would be useful to submit bugs for such packages when you encounter them. Package maintainers often do not use NIS/LDAP etc. so they have no experience in this area. Being nice to distributed NSS is seldom hard if you understand the common problems. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Am 2005-10-26 14:51:00, schrieb Humberto Massa: It seems that you still did not get my point. My point is, in a SoHo workstation, this is exactly the most common scenario nowadays (example: hmm. let me try this new dvd-player... I open synaptic, install it, ... nah, it does not work as I expected [but it installed gstreamer, jackd, etc in the process] let me try the next one in the list...) ??? - I know only $USER of a propietary OS which do install all the time because they are never satisfait. My Office Workstation is Woody since r0 and in the last 2 years I have installed only 48 new packages. My Dual-Opteron 240 (Devel-Station) requires nearly every day installations of Packages but never I have had so much System-Users laying around... Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Am 2005-10-26 14:51:00, schrieb Humberto Massa: It seems that you still did not get my point. My point is, in a SoHo workstation, this is exactly the most common scenario nowadays (example: hmm. let me try this new dvd-player... I open synaptic, install it, ... nah, it does not work as I expected [but it installed gstreamer, jackd, etc in the process] let me try the next one in the list...) ??? - I know only $USER of a propietary OS which do install all the time because they are never satisfait. My Office Workstation is Woody since r0 and in the last 2 years I have installed only 48 new packages. My Dual-Opteron 240 (Devel-Station) requires nearly every day installations of Packages but never I have had so much System-Users laying around... Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Hello Humberto, Am 2005-10-26 14:30:32, schrieb Humberto Massa: Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. Realy interesting... I have counted the System-Users on my 146 Machines The biggest machine has 72 and the smallest 48. Q: What do you do with your machine(s)? Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Florian Weimer wrote: * Steve Langasek: Frank Lichtenheld has already posted an announcement[4] detailing the release team's plans for the question of non-DFSG documentation in main. Just to clarify, is technical documentation that is only available in non-editable formats (e.g. Postscript files) Be wary of saying is only available in non-editable formats, since anyone with a hex editor will note that there is no such thing; and you've already been nitpicked for using Postscript files as an example. What you actually mean to say is is not available in the preferred form for modification (e.g. Postscript files generated from unpublished source files). Boy, we spent a long time on debian-legal hashing that sort of wording detail out. Anyway, with that clarification, no, such material is not DFSG-free. or can only be rebuilt with non-free tools or resources (such as certain fonts[1]) If the document can only be rebuilt with non-free tools, but the document itself (both source and binary) has a free license, and the source is properly available, then it's considered DFSG-free, but must go in contrib so that main can remain self-contained. If it goes in 'main' it's not a freeness violation, however; it's simply a violation of the rule that main must be self-contained. Detail: If the binary embeds part of, for instance, a non-free font, then the font license must be checked to make sure that the font is free for that purpose, as nearly all of them are; this is the most ordinary use of a font, so if it isn't explicitly restricted, we may be able assume that permission is granted (an assumption we normally can't make). This is just the same as the rule that the license for a non-free compiler must grant appropriate freedoms for the library code it embeds into binaries, in order for the resulting binaries to be DFSG-free. This is really not different from programs. At all. considered DFSG-free at this stage, provided that their license permits modification, redistribution etc.? Answered above. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Sun, 30 Oct 2005 10:58:23 +1100, Brian May [EMAIL PROTECTED] wrote: That is my point - adduser will print a warning if the user already exists. So you need to check to make sure the user doesn't exist first, before attempting to add it. Or you get a stupid warning appearing when upgrading packages. If you feel disturbed by the warning, redirect addusers output to /dev/null. It is specially tailored to not kill the package install if the user already exists. or in a practical sense either: [EMAIL PROTECTED]:~# adduser aaa adduser: The user `aaa' already exists. [EMAIL PROTECTED]:~# adduser --quiet aaa adduser: The user `aaa' already exists. (this is sarge/stable - maybe it has changed in unstable?) Probably not. Maybe one should add an option to suppress these messages on request. An appropriate patch would be appreciated. [1] What is a progress message? Probably inappropriate wording for adduser. An appropriate patch would be appreciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Bits from the release team: the plans for etch
su, 2005-10-30 kello 10:37 +0100, Marc Haber kirjoitti: On Sun, 30 Oct 2005 10:58:23 +1100, Brian May [EMAIL PROTECTED] wrote: That is my point - adduser will print a warning if the user already exists. So you need to check to make sure the user doesn't exist first, before attempting to add it. Or you get a stupid warning appearing when upgrading packages. If you feel disturbed by the warning, redirect addusers output to /dev/null. It is specially tailored to not kill the package install if the user already exists. This means that all other error messages will go to /dev/null as well. adduser can fail for other reasons and it is not acceptable to make it harder to debug for the sysadmin. I've stumbled upon several packages doing that, and filed bugs on them, when testing things with piuparts, which happened to create a chroot that was valid, but caused chage, and therefore adduser, to fail. Packages that hid adduser's error messages were much more annoying to deal with than those that let chage's error message be visible. I don't know perl, so I can't create a patch, sorry, but at a guess changing the dief call around 693 to something that doesn't print out an error message if --quiet has been given would seem to do the trick. -- I sometimes mistake arrogance for intelligence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Marc == Marc Haber [EMAIL PROTECTED] writes: Marc On Thu, 27 Oct 2005 08:54:18 +1000, Brian May Marc [EMAIL PROTECTED] wrote: If the code just calls adduser, this would seem to be a bug, as adduser will exit with a warning if the user already exists (see #264570). (If I am mistaken here with the precise details it is because the man page has mislead me). Marc You are mistaken. adduser will print a warning that the user Marc already exists and then exit with a zero exit code, if the Marc already existing account conforms to the account attributes Marc requested in the adduser call. That is my point - adduser will print a warning if the user already exists. So you need to check to make sure the user doesn't exist first, before attempting to add it. Or you get a stupid warning appearing when upgrading packages. So either you have to redirect stderr to /dev/null (this could mask serious errors too), or just to make sure the user doesn't exist first (preferred IMHO). Marc You can also use adduser --quiet and get rid of the Marc warnings. Not according to the man page[1]: --quiet Suppress progress messages. or in a practical sense either: [EMAIL PROTECTED]:~# adduser aaa adduser: The user `aaa' already exists. [EMAIL PROTECTED]:~# adduser --quiet aaa adduser: The user `aaa' already exists. (this is sarge/stable - maybe it has changed in unstable?) However, this has to be done carefully, or you end up doing the wrong thing. e.g. deluser -r $USER, in the past, has been pure evil if the home directory has been changed to /! Marc Deluser has a configuratble regexp and refuses to delete Marc files matching that regexp. Good. Note: [1] What is a progress message? -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Steve Langasek [EMAIL PROTECTED] writes: On Thu, Oct 27, 2005 at 07:24:28AM -0500, Steve Greenland wrote: On 27-Oct-05, 04:39 (CDT), Jonas Meurer [EMAIL PROTECTED] wrote: it produces at least a bloated passwd/group/shadow file. Bloat? The /etc/passwd on my development machine, which has seen all kinds of random server installs and removes, has grown to a whole 2K. So it could double before expanding into a second disk block. Untidy, I'll grant you, but bloat seems excessive. Nah, the biggest hit isn't disk space, it's NSS lookup times from having to do a linear search through a flat-file /etc/passwd and /etc/shadow. Well, thank God no one uses pam_pwdb anymore, at least... An other issue that always annoyed me is that assuming a NIS server and a NIS client which both install say exim. I want to give some users membership in the group Debian-exim. I can't easily. The UID picked by Debian-exim is not going to be the same for the NIS server and all the NIS clients, so I cannot get it propagated by NIS. And I don't want to have to maintain the group membership on all the clients. Currently, the only decent solution is to force the same UID and GID on all the NIS machines. And propagate the membership through NIS. Yet some packages do not deal very well with that solution: some are confused by some user or group that they cannot modify with usermod or groupmod. Others are confused when removing the user or group (userdel and groupdel failing to remove a NIS entry). Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Miles Bader: Florian Weimer [EMAIL PROTECTED] writes: There are people in this world who can read and program PostScript. Sure, and it's the preferred form of modifcation for removing ink-wasting background images from Powerpoint presentations, but: This is not the kind of modifcation I'm talking about. Imagine you have to update the documentation to include an additional paragraph. You don't quite seem to be grokking the concept of Postscript as a source language. I don't care about the cases where Postscript is used as a source language. I've seen in some cases, sure, but it was artwork, and not documentation extending over several pages. I care about dvips output where we do not have the original source file (a LaTeX document). Or PDF files which come from Word documents which aren't publicly available. Is this so hard to understand? Discussing the what is source code? aspect is certainly a nice way to sidestep the pretty much relevant question whether such issues should be RC bugs for etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PostScript can be the preferred form of modification (was: Bits from the release team: the plans for etch)
Florian Weimer [EMAIL PROTECTED] wrote: * Frank Küster: It is for sure not a bug to contain a PostScript file where PostScript is the preferred form of modification. If you have tetex-base installed, /usr/share/texmf/dvips/misc/resolution400.ps is a short example, /usr/share/texmf/dvips/misc/crops.pro is a bit longer. There are people in this world who can read and program PostScript. Sure, and it's the preferred form of modifcation for removing ink-wasting background images from Powerpoint presentations, but: This is not the kind of modifcation I'm talking about. I know, but you missed the point. PostScript can be the source, the preferred form of modification, in some cases, because PostScript is a programming language. This subthread started when you asked whether non-editable documentation was allowed in Debian, and you gave PostScript as an example format. Bernhard R. Link pointed out that PostScript is editable and can be the Preferred Form of Modification. I have given examples where this is the case (see the citation above). This means that whenever we write something down about removing non-free stuff we should be carefull to phrase it right, and not do it as you did in your mail: We should not write anything that might imply that all PostScript documents without any form of source must be removed from Debian. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bits from the release team: the plans for etch
Florian Weimer [EMAIL PROTECTED] wrote: * Miles Bader: Florian Weimer [EMAIL PROTECTED] writes: There are people in this world who can read and program PostScript. Sure, and it's the preferred form of modifcation for removing ink-wasting background images from Powerpoint presentations, but: This is not the kind of modifcation I'm talking about. Imagine you have to update the documentation to include an additional paragraph. You don't quite seem to be grokking the concept of Postscript as a source language. I don't care about the cases where Postscript is used as a source language. I've seen in some cases, sure, but it was artwork, and not documentation extending over several pages. Please have a look at the files I cited in an other mail in this thread. I care about dvips output where we do not have the original source file (a LaTeX document). Or PDF files which come from Word documents which aren't publicly available. Is this so hard to understand? We care about that too. But in addition, we care about proper phrasing. It is, of course, okay to say Documents where the preferred form for modification is not available cannot be included in Debian. It is not okay to say Documents that are only available in non-editable formats (e.g. PostScript) cannot be included in Debian, because PostScript is an editable format, and in some cases ist *is* the preferred form for modification. Discussing the what is source code? aspect is certainly a nice way to sidestep the pretty much relevant question whether such issues should be RC bugs for etch. The existing, real issues should be RC. Bugs that only show that people haven't understood what source code is should be closed. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bits from the release team: the plans for etch
* Quoting Gabor Gombas ([EMAIL PROTECTED]): So, how can the administrator tell dpkg do _not_ remove this account even if some package's postrm tries to purge it? If there would be a method to mark some accounts out-of-reach for automatic removal, that would settle this issue I think. The admin should know whether he messed with the account and if he did just remove the package instead of purging it. It's not like packages get purged by themself. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Thu, 27 Oct 2005 08:54:18 +1000, Brian May [EMAIL PROTECTED] wrote: If the code just calls adduser, this would seem to be a bug, as adduser will exit with a warning if the user already exists (see #264570). (If I am mistaken here with the precise details it is because the man page has mislead me). You are mistaken. adduser will print a warning that the user already exists and then exit with a zero exit code, if the already existing account conforms to the account attributes requested in the adduser call. So either you have to redirect stderr to /dev/null (this could mask serious errors too), or just to make sure the user doesn't exist first (preferred IMHO). You can also use adduser --quiet and get rid of the warnings. However, this has to be done carefully, or you end up doing the wrong thing. e.g. deluser -r $USER, in the past, has been pure evil if the home directory has been changed to /! Deluser has a configuratble regexp and refuses to delete files matching that regexp. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Bits from the release team: the plans for etch
On Wed, 26 Oct 2005 14:15:41 +0200, Gabor Gombas [EMAIL PROTECTED] wrote: If you want to allow automatic user/group removal, then adduser should be extended to remember every UID/GID that was ever used by a system user, and never reuse them again even if they have since been removed from /etc/passwd and/or /etc/group. Feel free to submit a patch to bug 248500. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Removing system users on purge [Re: Bits from the release team: the plans for etch]
Stephen Frost [EMAIL PROTECTED] wrote: * Don Armstrong ([EMAIL PROTECTED]) wrote: On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote: On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote: What about log files with sensitive content? Non-issue, as I said in the end of my post, those should be removed on purge. The log files that are created by the default package configuration should be removed, but custom modifications to the configuration can cause logfiles to be created elsewhere that are owned by the user in question. Have we actually got a specific case of this happening and there being a real security threat from it? When I ran a samba server years ago, I changed the default log file names and, IIRC, location. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bits from the release team: the plans for etch
On Wed, 26 Oct 2005 22:38:44 +0100, Stephen Gran [EMAIL PROTECTED] wrote: add user chown a bunch of stuff to the new user start the daemon Correct me if I'm wrong, but I'm imagining this dh_ fragment being added by the DEBHELPER blob at the end, and so anything needed to be done in between adding the user and starting the daemon (the other common and useful debhelper fragment in this sort of case) kind of blows up. Unless I'm missing the way you were going to implement this. Right. Now I remember that this was actually the cause for me dropping my idea of dh_user and instead working on adduser to have it useable painlessly. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Bits from the release team: the plans for etch
On 26/10/2005 Thomas Bushnell BSG wrote: Humberto Massa [EMAIL PROTECTED] writes: Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. And what bad results does this produce? it produces at least a bloated passwd/group/shadow file. This is reason enough to consider possible solutions. i agree with Javier Fernandez-Sanguino Pena that accounts should be removed by the packages which created them. As a backdoor, the adduser package could ask once via debconf whether you want to keep accounts after package purge, for sysadmins who don't want system accounts to be removed at package purges. i quite understand that some sysadmins don't like the idea of system accounts being removed at package purge, but others don't like the idea of a bloated /etc/passwd, so the best would be to provide both possibilities. that could be realized by a appropriate debconf question. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On 26/10/2005 Andreas Barth wrote: * Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]: in my workstation I try out a new package (for scientfic computing, a game for Lucas, a new development package) at least once each two days, and a lot of times they come with their libs and their daemons -- and their users. So I see them, and think oh, no, this is not what I thought it would be, and --purge them. And the daemons' users pile up in /etc/passwd. well, perhaps take it as administrators job to clean up /etc/passwd from time to time if you install that many packages (because you as administrator know which users were co-used with someone else, and which not). But this is definitly not the most common scenario. this may be valid for servers with real sysadmins who have an overview over packages, users, etc. installed on the system. for desktop systems where no system 'administrator' exists, for example because nobody has the knowledge to understand /etc/passwd, it is not true. the argument could be used for everything, and we would not need quality checks as piuparts at all, as everything that packages leave on the system, could be defined as 'administrators job'. but we try to make packages better for our users, and one issue in doing so is dealing with system accounts. if a package creates a system user who is intended to be used by the package only, the package should remove the user at purge time. if the administrator uses the system user for other tasks, it's his/her decision, and dealing with the situation is 'administrators job'. the current thread shows, that both opinions exist and that both situations need to be supported. therefore i suggest to add a debconf question to adduser, to ask the local sysadmin for his/her preference. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Bernhard R. Link: * Florian Weimer [EMAIL PROTECTED] [051025 13:51]: * Steve Langasek: Frank Lichtenheld has already posted an announcement[4] detailing the release team's plans for the question of non-DFSG documentation in main. Just to clarify, is technical documentation that is only available in non-editable formats (e.g. Postscript files) Little nitpick and petition: Please write generated Postscript files in such examples, as postscript files can be perfectly editable and only the existance of easier languages causes the vast majority of postscript files being generated non-editable forms. (As is assembler files currently, or as C source code would be if almost everyone switched to some other language with a compiler generating C code as intermediate format.) On systems without digital restrictions managemet without mandatory enforcement [1], it goes without saying that you can change bytes as you like, but it is hardly the preferred way of implementing modifications. Is it really controversial that these problems are bugs? I assumed that only the RC status could be subject to debate. 1. Both the kernel and GCC include DRM, but without mandatory enforcement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Florian Weimer [EMAIL PROTECTED] wrote: * Bernhard R. Link: * Florian Weimer [EMAIL PROTECTED] [051025 13:51]: * Steve Langasek: Frank Lichtenheld has already posted an announcement[4] detailing the release team's plans for the question of non-DFSG documentation in main. Just to clarify, is technical documentation that is only available in non-editable formats (e.g. Postscript files) Little nitpick and petition: Please write generated Postscript files in such examples, as postscript files can be perfectly editable and only the existance of easier languages causes the vast majority of postscript files being generated non-editable forms. (As is assembler files currently, or as C source code would be if almost everyone switched to some other language with a compiler generating C code as intermediate format.) On systems without digital restrictions managemet without mandatory enforcement [1], it goes without saying that you can change bytes as you like, but it is hardly the preferred way of implementing modifications. Is it really controversial that these problems are bugs? I assumed that only the RC status could be subject to debate. It is for sure not a bug to contain a PostScript file where PostScript is the preferred form of modification. If you have tetex-base installed, /usr/share/texmf/dvips/misc/resolution400.ps is a short example, /usr/share/texmf/dvips/misc/crops.pro is a bit longer. There are people in this world who can read and program PostScript. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bits from the release team: the plans for etch
On Wednesday 26 October 2005 23:38, Stephen Gran wrote: While I appreciate the effort at a standard shell script fragment for 'install a user', and think that it would be useful as reference and for reuse, I tend to think making it a dh_ fragment doesn't work in the normal use cases I can think of. Ordinarily, when a package installs a user, the logic of the maintainer script goes something like: add user chown a bunch of stuff to the new user start the daemon If chowning a bunch of stuff is the only thing most package installs do couldn't you just add a file with a list of things to chown for the dh_user command to use? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp1hhjWhD3EC.pgp Description: PGP signature
Re: Bits from the release team: the plans for etch
On 27-Oct-05, 04:39 (CDT), Jonas Meurer [EMAIL PROTECTED] wrote: it produces at least a bloated passwd/group/shadow file. Bloat? The /etc/passwd on my development machine, which has seen all kinds of random server installs and removes, has grown to a whole 2K. So it could double before expanding into a second disk block. Untidy, I'll grant you, but bloat seems excessive. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Thu, Oct 27, 2005 at 07:24:28AM -0500, Steve Greenland wrote: On 27-Oct-05, 04:39 (CDT), Jonas Meurer [EMAIL PROTECTED] wrote: it produces at least a bloated passwd/group/shadow file. Bloat? The /etc/passwd on my development machine, which has seen all kinds of random server installs and removes, has grown to a whole 2K. So it could double before expanding into a second disk block. Untidy, I'll grant you, but bloat seems excessive. Nah, the biggest hit isn't disk space, it's NSS lookup times from having to do a linear search through a flat-file /etc/passwd and /etc/shadow. Well, thank God no one uses pam_pwdb anymore, at least... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Removing system users on purge [Re: Bits from the release team: the plans for etch]
* Frank K?ster ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] wrote: Have we actually got a specific case of this happening and there being a real security threat from it? When I ran a samba server years ago, I changed the default log file names and, IIRC, location. Were they owned by the samba uid? Were they terribly sensitive? Did you ever actually uninstall samba? Was the samba uid reused? Was there an actual compramise of the files by another daemon? I'm looking for actual cases of this 'security hole' being exploited, or even getting to the point where files ended up actually owned by the wrong uid. Thanks, Stephen signature.asc Description: Digital signature
Re: Removing system users on purge [Re: Bits from the release team: the plans for etch]
Stephen Frost [EMAIL PROTECTED] wrote: * Frank K?ster ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] wrote: Have we actually got a specific case of this happening and there being a real security threat from it? When I ran a samba server years ago, I changed the default log file names and, IIRC, location. Were they owned by the samba uid? I don't know for sure, but I think yes. Were they terribly sensitive? In some cases knowledge of filenames that one user uses would have been very interesting for some other users. Did you ever actually uninstall samba? Was the samba uid reused? Since I left that server to somebody else, I can only speculate: Probably no, but I cannot exclude it (e.g. if there ever was a samba-ng package or something like that, they might have tried it instead). Was there an actual compramise of the files by another daemon? I assume that in this case I'd know. I'm looking for actual cases of this 'security hole' being exploited, Sorry, I can't help you. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 02:51:00PM -0300, Humberto Massa wrote: It seems that you still did not get my point. My point is, in a SoHo workstation, this is exactly the most common scenario nowadays (example: hmm. let me try this new dvd-player... I open synaptic, install it, ... nah, it does not work as I expected [but it installed gstreamer, jackd, etc in the process] let me try the next one in the list...) Well, in this situation you are likely to try out several packages that turn out to be broken in some regard and leave other cruft behind besides unused accounts. So for example, why not extend cruft (or some other similar tool) to report and possibly remove unused accounts, when the admin feels like it's time to tidy up? That way the admin can _see_ that the account is to be removed and can stop if he thinks oh damn, I still use that. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Thu, Oct 27, 2005 at 11:54:10AM +0200, Jonas Meurer wrote: but we try to make packages better for our users, and one issue in doing so is dealing with system accounts. if a package creates a system user who is intended to be used by the package only, the package should remove the user at purge time. if the administrator uses the system user for other tasks, it's his/her decision, and dealing with the situation is 'administrators job'. So, how can the administrator tell dpkg do _not_ remove this account even if some package's postrm tries to purge it? If there would be a method to mark some accounts out-of-reach for automatic removal, that would settle this issue I think. the current thread shows, that both opinions exist and that both situations need to be supported. therefore i suggest to add a debconf question to adduser, to ask the local sysadmin for his/her preference. But that question should be asked at package _removal_ time. I surely would not remember what debconf questions have I answered two years ago when I installed the package. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Thu, Oct 27, 2005 at 05:53:16AM -0700, Steve Langasek wrote:
Nah, the biggest hit isn't disk space, it's NSS lookup times from having to
do a linear search through a flat-file /etc/passwd and /etc/shadow. Well,
thank God no one uses pam_pwdb anymore, at least...
One can use nscd if he/she is really concerned for that. But I think the
cost of a hundred extra entries in /etc/{passwd,group} would stills be
lost in the noise compared to distributed NSS methods like NIS, NIS+ or
LDAP.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Frank Küster: It is for sure not a bug to contain a PostScript file where PostScript is the preferred form of modification. If you have tetex-base installed, /usr/share/texmf/dvips/misc/resolution400.ps is a short example, /usr/share/texmf/dvips/misc/crops.pro is a bit longer. There are people in this world who can read and program PostScript. Sure, and it's the preferred form of modifcation for removing ink-wasting background images from Powerpoint presentations, but: This is not the kind of modifcation I'm talking about. Imagine you have to update the documentation to include an additional paragraph. Do you really think it's acceptable to perform major Postscript surgery on the following pages, until you hit a page with sufficient free vertical space? (In some ways, this is harder than patching binary executables!)
Re: Bits from the release team: the plans for etch
Jonas Meurer [EMAIL PROTECTED] writes: it produces at least a bloated passwd/group/shadow file. This is reason enough to consider possible solutions. You're worried about disk consumption? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 11:07:11AM -0700, Thomas Bushnell BSG wrote: Moreover, the consequences of getting the one wrong are that you delete the sysadmin's changes. It can be worse. If you create a directory for working files which you remove on package removal (with rmdir), but which contains local backups the administrator made, then removing the user could leave that directory owned by another package. Now while the package (and the user) is removed, another package with system user could be installed. If you now try to install the package again, you wouldn't be able to write to your own directory anymore, because you don't own it. Hence, the package might be totally broken. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On 27-Oct-05, 07:53 (CDT), Steve Langasek [EMAIL PROTECTED] wrote: Nah, the biggest hit isn't disk space, it's NSS lookup times from having to do a linear search through a flat-file /etc/passwd and /etc/shadow. Well, thank God no one uses pam_pwdb anymore, at least... I'd be willing to bet that you can look through a few hundred system accounts (which is way more than we're talking about removing) a lot quicker than you can get a reply from a remote LDAP server. Maybe not the first time, but once it's cached...and it will stay cached, if you're doing enough lookups to care. I'd also be willing to bet you can't reliably measure the difference removing 15 inactive sytem accounts makes to lookups on a system made in the last 10 years, at anything above the processor cycle level. (I suppose I should restrict that any semi-normal general purpose system, to keep someone from coming up with a 8080-based embedded system that reads /etc/password from paper tape.) Where people run into problems with the linear search is with 10K user accounts, which is irrelevant to what we're discussing. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Florian Weimer [EMAIL PROTECTED] writes: There are people in this world who can read and program PostScript. Sure, and it's the preferred form of modifcation for removing ink-wasting background images from Powerpoint presentations, but: This is not the kind of modifcation I'm talking about. Imagine you have to update the documentation to include an additional paragraph. You don't quite seem to be grokking the concept of Postscript as a source language. If the document was _written in Postscript_, then changes such as you mention will in fact be at least as easy as it was for the original author to write the document in the first place (and with good postscript coding, it can be quite easy), and that's all that's necessary to consider it as the preferred form of modification. Postscript is not _usually_ the source language / preferred form of modification, but sometimes it is. -Miles -- Most attacks seem to take place at night, during a rainstorm, uphill, where four map sheets join. -- Anon. British Officer in WW I -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: ? Have you looked at the code I added to the developer's reference _at_all_? Yes. Have you read adduser docs _at_all_? Creating system users needs to cope with the fact that users might have greated them before hand. adduser copes with that. If a system user to be created does already exist with the required properties, adduser is a no-op and exists with a zero exit code. If a system user to be created does already exist with different attributes, it exists with non-zero exit code, as this is an error. Thus, in most cases, a single call to adduser is all that's needed to create a system user in postinst. Your code, otoh, will overwrite local configuration which is an RC bug. There's some code that needs to be written to cope with different packaging situations that adduser is unable to contemplate by itself. Which situations? Not including the fact that the user created by a package might need to be removed on postinst. Removing system users on package purge is widely regarded a bug since one cannot guarantee that the local admin hasn't used the account for other things as well. Additionally, removing the system user on package purge might leave orphaned files around. If the maintainer decides to remove a user in postinst, that can be done with an explicit deluser call. Frankly, I do not see any advantage in your dh_user idea. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Bits from the release team: the plans for etch,L
Frankly, I do not see any advantage in your dh_user idea. I can see one...even if I follow this discussion quite loosely: Currently, all packages needing to add a system user do it their own way. Some do it very carefully with nice error checking and stuff, by using adduser, etc. Some others might do it less carefully...or slightly differently. Thus, a debhelper script for this could at least bring some consistency to these methods and, actually, offer lazy maintainers (we are all lazy maintainers) a convenient method for adding users. Just for this, I would probably appreciate a dh_user script. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Florian Weimer [EMAIL PROTECTED] [051025 13:51]: * Steve Langasek: Frank Lichtenheld has already posted an announcement[4] detailing the release team's plans for the question of non-DFSG documentation in main. Just to clarify, is technical documentation that is only available in non-editable formats (e.g. Postscript files) Little nitpick and petition: Please write generated Postscript files in such examples, as postscript files can be perfectly editable and only the existance of easier languages causes the vast majority of postscript files being generated non-editable forms. (As is assembler files currently, or as C source code would be if almost everyone switched to some other language with a compiler generating C code as intermediate format.) Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
Creating system users needs to cope with the fact that users might have
greated them before hand.
adduser copes with that. If a system user to be created does already
exist with the required properties, adduser is a no-op and exists with
a zero exit code. If a system user to be created does already exist
with different attributes, it exists with non-zero exit code, as this
is an error.
And that's something that packages maintainer scripts have to cope with since
they don't know beforehand if it's there and it certainly doe snot have the
same attirbutes (it might only share the name)
Thus, in most cases, a single call to adduser is all that's needed to
create a system user in postinst.
I have yet to see a package that just calls adduser. Some remove the user
(and fail to check if it was created by the postinst/preinst and not by the
alocal admin), some set additional groups, setup its home directory (uneless
defined with dpkg-statoverride already). I can provide you a script to show
you all the postinst/preinst/postrm of packages that create a user on
installation. You can see for yourself.
Your code, otoh, will overwrite local configuration which is an RC
bug.
Please explain, the code only changes /etc/{passwd,shadow,group}. Where's the
RC bug?
There's some code that needs to be written to cope
with different packaging situations that adduser is unable to
contemplate by itself.
Which situations?
For example:
- Creating the user's homedir and assigning proper permissions if (and only
if) the admin has not overriden it with dpkg-statoverride
- Adding the user to additional groups if required
Not including the fact that the user created by a
package might need to be removed on postinst.
Removing system users on package purge is widely regarded a bug since
one cannot guarantee that the local admin hasn't used the account for
other things as well. Additionally, removing the system user on
package purge might leave orphaned files around. If the maintainer
decides to remove a user in postinst, that can be done with an
explicit deluser call.
That really depends on the daemon itself don't you think? There's a number of
daemons that don't create any file at all or, if they do, are created
only on a given directory which is removed on purge. In these cases, removing
the user on postrm's purge might make sense. As I said, that would be an
option.
Frankly, I do not see any advantage in your dh_user idea.
Quite frankly, I do.
Javier
[1] Those are just some of the ones doing this. Full list:
lynx -nolist -dump
$
http://lintian.debian.org/reports/Tmaintainer-script-needs-depends-on-adduser.html
|perl -ne 'print $1.\n if /W: (.*?): /
$ grep-available -sPackage -FPre-Depends,Depends adduser | awk '{print $2}'
signature.asc
Description: Digital signature
Re: Bits from the release team: the plans for etch
On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
Thus, in most cases, a single call to adduser is all that's needed to
create a system user in postinst.
I have yet to see a package that just calls adduser.
Well, exim4, console-log, rageircd and ippl do. These are the ones
that I know for sure without thinking too long.
Some remove the user
(and fail to check if it was created by the postinst/preinst and not by the
alocal admin),
Removing the user is a general bug, IMO. They cannot guess what the
local admin did with the account while the package was installed.
Your code, otoh, will overwrite local configuration which is an RC
bug.
Please explain, the code only changes /etc/{passwd,shadow,group}. Where's the
RC bug?
If I generate user foo and give it some attributes, and some packages
comes and overwrites these attributes, it has overwritten local
configguration, and I would be Not Amused. The only sensible thing
that a package can do in this situation is abort installation.
Some packages have tried to minimize the collision probability by
using a prefix such as Debian- for their account, but until Debian
has established Policy about that it's only a token measure.
There's some code that needs to be written to cope
with different packaging situations that adduser is unable to
contemplate by itself.
Which situations?
For example:
- Creating the user's homedir and assigning proper permissions if (and only
if) the admin has not overriden it with dpkg-statoverride
What are proper permissions other than user:usersgroup 755, as
configured for the entire systems?
- Adding the user to additional groups if required
adduser user group
Removing system users on package purge is widely regarded a bug since
one cannot guarantee that the local admin hasn't used the account for
other things as well. Additionally, removing the system user on
package purge might leave orphaned files around. If the maintainer
decides to remove a user in postinst, that can be done with an
explicit deluser call.
That really depends on the daemon itself don't you think?
No. You never know what the local admin uses an account for.
Frankly, I do not see any advantage in your dh_user idea.
Quite frankly, I do.
Go ahead. Maybe it's still even useful. Just the fact that I ditched
the plans for writing something like that doesn't mean that it might
not be useful. I'd just prefer adduser to take that task without
external help because collaboration might be useful.
For example, having the possibility to add a new account to a list of
groups _in_ _adduser_ would close two wishlist bugs against adduser
and ease account creation for the installer. Having that feature
added externally doesn't help here and indeed decreases the chance
for these wishlist bugs to be addressed in any reasonable time frame.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Peńa wrote: That really depends on the daemon itself don't you think? There's a number of daemons that don't create any file at all or, if they do, are created only on a given directory which is removed on purge. In these cases, removing the user on postrm's purge might make sense. As I said, that would be an option. It is still possible that those daemons _read_ some files (e.g. config files), and the admin did a chown/chgrp to the daemon's user. Removing the user and reusing the UID/GID will suddenly make those files accessible for a random new package which may not be intended at all. IMHO you can safely remove an user/group _only_ if you have made sure there are no files owned by that uid/group left on any filesystems (and checking that may be tricky if the system uses ACLs, for example). And there is also the problem of files restored from a backup being suddenly owned by some random new user/group... At the very least you should ask the admin if he wants to remove the user/group on package purge (with the default being 'no'). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On 10/26/05, Gabor Gombas [EMAIL PROTECTED] wrote: On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Peńa wrote: That really depends on the daemon itself don't you think? There's a number of daemons that don't create any file at all or, if they do, are created only on a given directory which is removed on purge. In these cases, removing the user on postrm's purge might make sense. As I said, that would be an option. It is still possible that those daemons _read_ some files (e.g. config files), and the admin did a chown/chgrp to the daemon's user. Removing the user and reusing the UID/GID will suddenly make those files Removing the user is 'fine', it's the reusing that's the issue. But isn't that your own fault if you choose to reuse numbers?
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 02:00:17PM +0200, Olaf van der Spek wrote: Removing the user is 'fine', it's the reusing that's the issue. But isn't that your own fault if you choose to reuse numbers? If a package's postrm removes the user, and the next package's postinst just calls adduser, then the admin have no control over the reusing. If you want to allow automatic user/group removal, then adduser should be extended to remember every UID/GID that was ever used by a system user, and never reuse them again even if they have since been removed from /etc/passwd and/or /etc/group. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote: If a package's postrm removes the user, and the next package's postinst just calls adduser, then the admin have no control over the reusing. If you want to allow automatic user/group removal, then adduser should be extended to remember every UID/GID that was ever used by a system user, and never reuse them again even if they have since been removed from /etc/passwd and/or /etc/group. i don't think removing and reusing users is a good idea in practice. what harm would there be in simply leaving the user account on the system permenantly, with maybe locking the account and setting the shell to /bin/false? sean signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 08:20:02AM -0400, sean finney wrote: On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote: If a package's postrm removes the user, and the next package's postinst just calls adduser, then the admin have no control over the reusing. If you want to allow automatic user/group removal, then adduser should be extended to remember every UID/GID that was ever used by a system user, and never reuse them again even if they have since been removed from /etc/passwd and/or /etc/group. i don't think removing and reusing users is a good idea in practice. what harm would there be in simply leaving the user account on the system permenantly, with maybe locking the account and setting the shell to /bin/false? In the general case, I can think of two reasons to remove users (but leave the ids reserved): namespace pollution, and user lookup performance when using flatfile /etc/passwd. Neither of these is particularly relevant for system accounts, but if adduser gained support for something like this I don't see any reason for system accounts to *not* use it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
hey steve, On Wed, Oct 26, 2005 at 05:29:46AM -0700, Steve Langasek wrote: In the general case, I can think of two reasons to remove users (but leave the ids reserved): namespace pollution, and user lookup performance when using flatfile /etc/passwd. Neither of these is particularly relevant for system accounts, but if adduser gained support for something like this I don't see any reason for system accounts to *not* use it. i was speaking specifically about system accounts, i guess i didn't make that clear. i can see all kinds of wierd problems hapenning when a system-account is removed, but still owning files on the filesystem (perhaps not even files managed by dpkg), and later more system accounts are created. i suppose this could be addressed by reserving uid/account pairs so the subsequent additions of the user took the same uid and no other accounts would take it, but that seems like a whole lot of work to do and for no good reason in the first place. sean -- signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
* Marc Haber ([EMAIL PROTECTED]) wrote:
On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
Some remove the user
(and fail to check if it was created by the postinst/preinst and not by the
alocal admin),
Removing the user is a general bug, IMO. They cannot guess what the
local admin did with the account while the package was installed.
I disagree with the idea that removing a user is a bug. If the user was
added by the package, and the package is being purged, and there's a
reasonable expectation that it wasn't used outside of the package's use
of it then I think it's probably safe to remove it. sshd is a good
example of this, imv. I'm already unhappy about the clutter in my
passwd/shadow files, having packages never be allowed to remove users
(which they created originally, etc) would just make it that much worse
for me, as a user.
Please explain, the code only changes /etc/{passwd,shadow,group}. Where's the
RC bug?
If I generate user foo and give it some attributes, and some packages
comes and overwrites these attributes, it has overwritten local
configguration, and I would be Not Amused. The only sensible thing
that a package can do in this situation is abort installation.
I'm not entirely sure I agree that's the *only* sensible thing which
could be done. Could it be posed as a question to the admin, use the
attributes as specified, or change them? Depending on the capabilities
of the package, of course.
Some packages have tried to minimize the collision probability by
using a prefix such as Debian- for their account, but until Debian
has established Policy about that it's only a token measure.
The whole Debian- bit is just dumb(tm). Of course, so is hard-coding
usernames into packages (it's even better when there's a config option
to specify the username!). Collisions need to be dealt with in some
sane way, just attempting to avoid them is foolishness. What if the
admin *does* create a Debian-blah system account? I don't think just
overriding what the admin did would be right in that case either,
'reserved' namespace or not.
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 12:16:43PM +0200, Marc Haber wrote:
On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
Please explain, the code only changes /etc/{passwd,shadow,group}. Where's the
RC bug?
If I generate user foo and give it some attributes, and some packages
comes and overwrites these attributes, it has overwritten local
configguration, and I would be Not Amused. The only sensible thing
that a package can do in this situation is abort installation.
Hmm.. I guess you refer to the usermod use, which could be moved into the 'if
getent passwd' clause. Aborting installation when the user already
exists is something that could be avoided.
Some packages have tried to minimize the collision probability by
using a prefix such as Debian- for their account, but until Debian
has established Policy about that it's only a token measure.
That's precisely why providing a best practices is needed. Currently there
are too many packages using their own implementation of the above, if there
is no consensus on how it should be implemented there can hardly be a policy
item for those.
- Creating the user's homedir and assigning proper permissions if (and only
if) the admin has not overriden it with dpkg-statoverride
What are proper permissions other than user:usersgroup 755, as
configured for the entire systems?
For security reasons, it might make sense for some daemon files/directories
to be 640 (750 for dirs) or, even 600 (700 for dirs). Some daemons handle
sensible information in their directories which should be not be available
for other users.
- Adding the user to additional groups if required
adduser user group
Which needs to be done:
a) once the user has been created
b) once the group has been created
So it's three calls to adduser in that case:
- create the user
- create the group
- add the user to the group
That really depends on the daemon itself don't you think?
No. You never know what the local admin uses an account for.
Packages should not try to cope with every possible thing an admin can do.
There should be flexibility to have the admin make an informed decission, but
there should be a sane default valid for most installations. That's why
removal might be an optional feature in a 'dh_user' implementation which
should be, even, handled by a debconf question. Again, more code that is the
same across packages and could be added into the maintainer scripts
automatically by dh_user.
For example, having the possibility to add a new account to a list of
groups _in_ _adduser_ would close two wishlist bugs against adduser
and ease account creation for the installer. Having that feature
added externally doesn't help here and indeed decreases the chance
for these wishlist bugs to be addressed in any reasonable time frame.
The fact is, those features are already added externally, in inconsistent
ways, and without a clear policy stating how it should be implemente. So
maintainers can close bugs related to their decissions freely even if they
don't agree with the general consensus. So there is no difference if a
'dh_user' is written. With the added benefit that it would:
- make implementation uniforms and favor code reuse
- define a common practice that would later be able to turn into policy
IMHO of course.
Javier
signature.asc
Description: Digital signature
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote:
On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a
wrote:
That really depends on the daemon itself don't you think? There's a number
of
daemons that don't create any file at all or, if they do, are created
only on a given directory which is removed on purge. In these cases,
removing
the user on postrm's purge might make sense. As I said, that would be an
option.
It is still possible that those daemons _read_ some files (e.g. config
files), and the admin did a chown/chgrp to the daemon's user. Removing
the user and reusing the UID/GID will suddenly make those files
accessible for a random new package which may not be intended at all.
Wrong. That is only true in the chown() case. Which is not a sensible thing
to do. Daemons should be able to read their configuration files but they
usually *don't* need to *write* them, so they should *not* own them. The
reasoning for this is that if a security vulnerability is found that affects
the daemon, and it can write to its configuration file, then you are
introducing additional risks beyond the vulnerability itself. Think for
example:
- a chrooted() FTP server that can write to its configuration files or to the
applications in the chroot
- a web server that can write in its web page space area.
- a SSH server that can write to sshd_config (and, consequently, can enable
subsystems, authentication methods or remove limitations set by the admin)
If you find daemons which have their configuration files chown'ed to them
withouth there being a need to write to, please file a bug.
Now, baring the chown() case, you have two think of two type of configuration
files: those that hold sensitive information and those that do not. If they
don't hold sensitive information then you make those world readable, if they
do then you use a group, which can be shared by different packages or used by
only one package.
Here's an analysis of different situations for configuration files under
those premises:
[ File with sensitive information ]
- File is mode 640 and owned by root
- File belongs to the 'X' group, if the group is shared across packages then
the group should not be removed (or created) by the daemon package.
- Daemon 'D' belongs to the 'X' group, so he can read the file
Removal consequence: none. ¿Why? if the file is *not* shared across packages,
both the user, the group and the file should be removed _at_the_same_ time on
purge.
If the file is shared across packages (and is not a configuration file of the
daemon package), removal (or purge) of the daemon cannot lead to the removal
of the shared group. In either case, the file is not orphaned.
¿Can a new system daemon read the file?: no, unless he is added to the 'X'
group.
[ File without sensitive information ]
- File is mode 644 and owned by root, and belongs to 'root' group or
any other generic group ('adm')
- Daemon 'D' can read the file (due to it being world-readable)
Removal consequence: none, the file does not belong to the daemon user or its
group in any way, so it being remove cannot orphan the file.
¿Can a new system daemon read the file? Of course, the file is mode 644
The only situation where removing a daemon user is an issue is when the files
have either:
a- been created by the daemon through its normal operation
b- been created by the root user when impersonating the daemon
If the files hold to a) and are _not_ configuration files, log files, or
state files (i.e. under /var/run/, /var/state/, etc.) which should be removed
on purge as defined per policy, then the daemon should *not* be removed on
purge. This is the case of, for example, an MTA, which will create queue
files and spool files in normal operation.
If all the files in a) are purged and only b) remains as a possibility then
have the admin make a decission (and default to 'yes, remove' if appropiate)
Regards
Javier
signature.asc
Description: Digital signature
Re: Bits from the release team: the plans for etch
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote: On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a wrote: That really depends on the daemon itself don't you think? There's a number of daemons that don't create any file at all or, if they do, are created only on a given directory which is removed on purge. In these cases, removing the user on postrm's purge might make sense. As I said, that would be an option. It is still possible that those daemons _read_ some files (e.g. config files), and the admin did a chown/chgrp to the daemon's user. Removing the user and reusing the UID/GID will suddenly make those files accessible for a random new package which may not be intended at all. Wrong. That is only true in the chown() case. Which is not a sensible thing to do. Daemons should be able to read their configuration files but they usually *don't* need to *write* them, so they should *not* own them. What about log files with sensitive content? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 03:50:36PM +0200, Javier Fernández-Sanguino Peńa wrote: Wrong. That is only true in the chown() case. Which is not a sensible thing to do. Daemons should be able to read their configuration files but they usually *don't* need to *write* them, so they should *not* own them. That is true in general, but I've seen it enough times to say it is a common administration mistake. Of course, you can say that if the admin wants to shoot himself on the foot, let's give him a bigger gun... [ File with sensitive information ] - File is mode 640 and owned by root - File belongs to the 'X' group, if the group is shared across packages then the group should not be removed (or created) by the daemon package. - Daemon 'D' belongs to the 'X' group, so he can read the file Removal consequence: none. żWhy? if the file is *not* shared across packages, both the user, the group and the file should be removed _at_the_same_ time on purge. Here you assume that the packaging system knows about all such files, but that is simply not true. Simple example: a daemon that is capable of TLS. Now, the admin generates a certificate/key pair, and modifies the config file to use them. At this point, the packaging system has _zero_ knowledge that the cert/key files exist, so it can not remove them (and even parsing the config file to locate them would be wrong, since those files were generated by the admin therefore should never be removed by the package). Now, the key is likely having permission 640, owned by root, group is the daemon's group. This group is _not_ shared, so when the daemon is removed, the group is removed as well, and the next package installed that needs a system user/group will re-use the GID, thus it will have access to the private key. And this is a security problem, since having access to the private key even after the daemon has been removed can allow an attacker to decrypt network traffic recorded in the past. Also, even if the file is shared by multiple packages, there is _no_ guarantee that it uses a shared group. ACLs are supported by Linux for quite some time now. In fact it is quite reasonable to have a sensitive file being owned by root:root, having default access mask 0600, but granting read permission to other selected users via ACLs. This solution scales much better than creating a new group for every possible sharing combination. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* sean finney ([EMAIL PROTECTED]) [051026 14:20]: On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote: If a package's postrm removes the user, and the next package's postinst just calls adduser, then the admin have no control over the reusing. If you want to allow automatic user/group removal, then adduser should be extended to remember every UID/GID that was ever used by a system user, and never reuse them again even if they have since been removed from /etc/passwd and/or /etc/group. i don't think removing and reusing users is a good idea in practice. what harm would there be in simply leaving the user account on the system permenantly, with maybe locking the account and setting the shell to /bin/false? Yep, that's probably best practice. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: Removing system users on package purge is widely regarded a bug since one cannot guarantee that the local admin hasn't used the account for other things as well. Additionally, removing the system user on package purge might leave orphaned files around. If the maintainer decides to remove a user in postinst, that can be done with an explicit deluser call. That really depends on the daemon itself don't you think? There's a number of daemons that don't create any file at all or, if they do, are created only on a given directory which is removed on purge. In these cases, removing the user on postrm's purge might make sense. As I said, that would be an option. One cannot guarantee that the local admin hasn't used the account for other things as well. Please read. Thomas
Re: Bits from the release team: the plans for etch
Gabor Gombas [EMAIL PROTECTED] writes: IMHO you can safely remove an user/group _only_ if you have made sure there are no files owned by that uid/group left on any filesystems (and checking that may be tricky if the system uses ACLs, for example). Any filesystems here must include removable media not currently attached as well as garden-variety unmounted filesystems too. That's a tough task to automate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote: Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote: On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a wrote: That really depends on the daemon itself don't you think? There's a number of daemons that don't create any file at all or, if they do, are created only on a given directory which is removed on purge. In these cases, removing the user on postrm's purge might make sense. As I said, that would be an option. It is still possible that those daemons _read_ some files (e.g. config files), and the admin did a chown/chgrp to the daemon's user. Removing the user and reusing the UID/GID will suddenly make those files accessible for a random new package which may not be intended at all. Wrong. That is only true in the chown() case. Which is not a sensible thing to do. Daemons should be able to read their configuration files but they usually *don't* need to *write* them, so they should *not* own them. What about log files with sensitive content? Non-issue, as I said in the end of my post, those should be removed on purge. This is mandated by policy: http://www.debian.org/doc/debian-policy/ch-files.html#s10.8 Thus, at the same time that the user is removed and would never be orphaned. Case closed :-) Javier signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
Stephen Frost [EMAIL PROTECTED] writes: I disagree with the idea that removing a user is a bug. If the user was added by the package, and the package is being purged, and there's a reasonable expectation that it wasn't used outside of the package's use of it then I think it's probably safe to remove it. How do you acquire that expectation? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 05:24:46PM +0200, Gabor Gombas wrote:
On Wed, Oct 26, 2005 at 03:50:36PM +0200, Javier Fernández-Sanguino Pe?a
wrote:
Wrong. That is only true in the chown() case. Which is not a sensible thing
to do. Daemons should be able to read their configuration files but they
usually *don't* need to *write* them, so they should *not* own them.
That is true in general, but I've seen it enough times to say it is a
common administration mistake. Of course, you can say that if the admin
wants to shoot himself on the foot, let's give him a bigger gun...
[ File with sensitive information ]
- File is mode 640 and owned by root
- File belongs to the 'X' group, if the group is shared across packages then
the group should not be removed (or created) by the daemon package.
- Daemon 'D' belongs to the 'X' group, so he can read the file
Removal consequence: none. ?Why? if the file is *not* shared across
packages,
both the user, the group and the file should be removed _at_the_same_ time
on purge.
Here you assume that the packaging system knows about all such files, but
that is simply not true. Simple example: a daemon that is capable of
TLS. Now, the admin generates a certificate/key pair, and modifies the
config file to use them. At this point, the packaging system has _zero_
knowledge that the cert/key files exist, so it can not remove them (and
even parsing the config file to locate them would be wrong, since those
files were generated by the admin therefore should never be removed by
the package).
Correct, they should not be removed, but since configuration files should
reside in /etc, even better, in /etc/$daemon, it would just be a matter of
having a postrm test on purge that, once removed the conffiles from
the package, checks if there are files there and asks the admin on what
action to take (or warns him that they might get orphaned, or decides not to
remove the user even if the admin answered the debconf question saying yes,
remove this).
Notice that policy, again, mandates that backups of conffiles should be purged
(http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails)
so packages should already have some kind of test to check to look for stale
files in
configuration directories (that's not true for all, but those who don't are
buggy, so follow my point here). AS the precise naming of backup files is
open (from the manual: ~-files, #*# files, %-files, .dpkg-{old,new,tmp},
etc.) so the easiest way to test for the policy requirement is to check if
the configuration directory the package uses and see if it's empty after
removing all conffiles.
A standard test should cover both cases: backup files created by the admin
and new configuration files created by the admin there. Again, something that
could be reused by packages and integated into debhelp to prevent eveyrone
from writing his own piece of (sometimes buggy) code in maintainer scripts.
Of course, if the admin created the files outside of /etc/ (or /etc/$daemon)
then he would be on his own here [1]. That's why, again, the system user removal
should not be forced on all users, so knowledgeable users can say no, don't
remove this user, I'm going to do stuff with it. But it should be a =
medium debconf question.
Regards
Javier
[1] Running 'find /' is not an option since that could could be equivalent to
a DoS in some systems (those connected to SANs through network drives, for
example)
signature.asc
Description: Digital signature
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 05:39:45PM +0200, Andreas Barth wrote: i don't think removing and reusing users is a good idea in practice. what harm would there be in simply leaving the user account on the system permenantly, with maybe locking the account and setting the shell to /bin/false? Yep, that's probably best practice. Note that most system groups are already locked and have the shell set to /bin/false by default, anything else is likely a change made by the admin manually. Forcibly locking the account is thus overriding the admin's decision, so it must be at least clearly documented somewhere. Another thing would be to change the GECOS indicating that the account is now stale, and have some small utility to list/remove all such accounts. So whoever wants to automatically remove unused accounts can configure apt to do so by calling this utility from DPkg::Post-Invoke. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: I disagree with the idea that removing a user is a bug. If the user was added by the package, and the package is being purged, and there's a reasonable expectation that it wasn't used outside of the package's use of it then I think it's probably safe to remove it. How do you acquire that expectation? By knowing what the package uses the user for. This is somewhat akin to the PostgreSQL package's question do you want your data files to be purged upon package removal, or the fact that the default Postgres installation uses ident and the 'postgres' user is the superuser for the database (meaning you're going to be su'ing to postgres probably a fair bit). In this example, if the user said to remove the data files when the package is removed I'd expect the user to be removed as well. If the user said to *not* remove the data files (the default, I believe), then the postgres user should also remain. Another good example is the 'sshd' user, who owns nothing and is nothing more than a distinct unprivileged user for the purpose of communicating with the network in privsep mode (iirc). Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
* Andreas Barth ([EMAIL PROTECTED]) wrote: * sean finney ([EMAIL PROTECTED]) [051026 14:20]: i don't think removing and reusing users is a good idea in practice. what harm would there be in simply leaving the user account on the system permenantly, with maybe locking the account and setting the shell to /bin/false? Yep, that's probably best practice. In a 'best practice' setup, I'd think it's certainly be much better for unused accounts to not exist than to have them exist but be locked out through some means. I'm not a huge fan of trusting 'lock-out' mechanisms as they can be different for different authentication systems. Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 08:44:12AM -0700, Thomas Bushnell BSG wrote: One cannot guarantee that the local admin hasn't used the account for other things as well. Please read. We cannot guarantee that an admin fiddles with binaries in /usr/bin/ (as opposed to /usr/local/bin) either. That doesn't mean that packages have to cope with that situation. Again: We can provide a sensible default for system users' removals that copes with most situations and leave a door open (through debconf) to sysadmins that want to fiddle with system users. Heck, it can even be a generic debconf question shared across packages, so that the sysadmin has no need to answer it for every package. And, again, if the sysadmin is _supposed_ to use the account for other things then there should be no removal action and no question asked at all. Regards Javier signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
* Gabor Gombas ([EMAIL PROTECTED]) [051026 18:03]: On Wed, Oct 26, 2005 at 05:39:45PM +0200, Andreas Barth wrote: i don't think removing and reusing users is a good idea in practice. what harm would there be in simply leaving the user account on the system permenantly, with maybe locking the account and setting the shell to /bin/false? Yep, that's probably best practice. Note that most system groups are already locked and have the shell set to /bin/false by default, anything else is likely a change made by the admin manually. Forcibly locking the account is thus overriding the admin's decision, so it must be at least clearly documented somewhere. Well, locking of course only if the application needed something else than /bin/false in the first place. :) Another thing would be to change the GECOS indicating that the account is now stale, and have some small utility to list/remove all such accounts. So whoever wants to automatically remove unused accounts can configure apt to do so by calling this utility from DPkg::Post-Invoke. That might be possible, yes. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]: We can provide a sensible default for system users' removals that copes with most situations and leave a door open (through debconf) to sysadmins that want to fiddle with system users. I really want to warn to try to be too smart by half. Reserving the name/uid-space by not removing the accounts works reasonable well, and having at maximum 5-10 unnecessary accounts is also not the end of the world either. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Andreas Barth wrote: * Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]: We can provide a sensible default for system users' removals that copes with most situations and leave a door open (through debconf) to sysadmins that want to fiddle with system users. I really want to warn to try to be too smart by half. Reserving the name/uid-space by not removing the accounts works reasonable well, and having at maximum 5-10 unnecessary accounts is also not the end of the world either. Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. -- HTH, Massa
Re: Bits from the release team: the plans for etch
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:28]: Andreas Barth wrote: * Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]: We can provide a sensible default for system users' removals that copes with most situations and leave a door open (through debconf) to sysadmins that want to fiddle with system users. I really want to warn to try to be too smart by half. Reserving the name/uid-space by not removing the accounts works reasonable well, and having at maximum 5-10 unnecessary accounts is also not the end of the world either. Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. How many daemon packages do you install in two years? I even doubt that we have 100 packages that add accounts at all in debian. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Andreas Barth wrote: * Humberto Massa ([EMAIL PROTECTED]) [051026 18:28]: Andreas Barth wrote: * Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]: We can provide a sensible default for system users' removals that copes with most situations and leave a door open (through debconf) to sysadmins that want to fiddle with system users. I really want to warn to try to be too smart by half. Reserving the name/uid-space by not removing the accounts works reasonable well, and having at maximum 5-10 unnecessary accounts is also not the end of the world either. Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. How many daemon packages do you install in two years? I even doubt that we have 100 packages that add accounts at all in debian. count them and you'll see. Remember sarge has 17000 packages, how many of those do you think can add a user? in my workstation I try out a new package (for scientfic computing, a game for Lucas, a new development package) at least once each two days, and a lot of times they come with their libs and their daemons -- and their users. So I see them, and think oh, no, this is not what I thought it would be, and --purge them. And the daemons' users pile up in /etc/passwd. -- HTH Massa
Re: Bits from the release team: the plans for etch
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]: in my workstation I try out a new package (for scientfic computing, a game for Lucas, a new development package) at least once each two days, and a lot of times they come with their libs and their daemons -- and their users. So I see them, and think oh, no, this is not what I thought it would be, and --purge them. And the daemons' users pile up in /etc/passwd. well, perhaps take it as administrators job to clean up /etc/passwd from time to time if you install that many packages (because you as administrator know which users were co-used with someone else, and which not). But this is definitly not the most common scenario. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Andreas Barth wrote: * Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]: in my workstation I try out a new package (for scientfic computing, a game for Lucas, a new development package) at least once each two days, and a lot of times they come with their libs and their daemons -- and their users. So I see them, and think oh, no, this is not what I thought it would be, and --purge them. And the daemons' users pile up in /etc/passwd. well, perhaps take it as administrators job to clean up /etc/passwd from time to time if you install that many packages (because you as administrator know which users were co-used with someone else, and which not). But this is definitly not the most common scenario. It seems that you still did not get my point. My point is, in a SoHo workstation, this is exactly the most common scenario nowadays (example: hmm. let me try this new dvd-player... I open synaptic, install it, ... nah, it does not work as I expected [but it installed gstreamer, jackd, etc in the process] let me try the next one in the list...) -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:48]: Andreas Barth wrote: * Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]: in my workstation I try out a new package (for scientfic computing, a game for Lucas, a new development package) at least once each two days, and a lot of times they come with their libs and their daemons -- and their users. So I see them, and think oh, no, this is not what I thought it would be, and --purge them. And the daemons' users pile up in /etc/passwd. well, perhaps take it as administrators job to clean up /etc/passwd from time to time if you install that many packages (because you as administrator know which users were co-used with someone else, and which not). But this is definitly not the most common scenario. It seems that you still did not get my point. My point is, in a SoHo workstation, this is exactly the most common scenario nowadays (example: hmm. let me try this new dvd-player... I open synaptic, install it, ... nah, it does not work as I expected [but it installed gstreamer, jackd, etc in the process] let me try the next one in the list...) I fear, you still did not get my point. We have two ways to choose from, both with advantages and disadvantages. One has the disadvantage to be able to make systems magically fail and expose security risks. The other has the disadvantage to make /etc/passwd a bit too large in some cases. Isn't it obvious that we shouldn't go for the security risk? I don't mind at all if we get some clever way like marking the user in the gecos-field and have an debuserfoster. But I mind very much to try to deal security with looks nicer. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
ke, 2005-10-26 kello 14:30 -0300, Humberto Massa kirjoitti: Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. It would certainly be good if we had a system for marking accounts as unused by a package, and then give the sysadmin a tool for removing them. Like, say, the postrm script could call automatic-deluser, which reads /ec/default/automatic-deluser, and if METHOD is set to always-remove, removes the account, otherwise sets the shell to to /bin/no-longer-in-use-by-package. The sysadmin can run remove-autodeleted-accounts to remove accounts marked that way. . /etc/default/automatic-deluser if [ $METHOD = always-remove ]] then deluser $1 else chsh -s /bin/no-longer-in-use-by-package $1 fi (Anyone running the above code should be aware that it is untested and will probably replace your kernel with MS-DOS 2.11.) The default value for METHOD probably should not be always-remove. As has been pointed out in this thread, there are risks involved with that. The cost is that for most people, there might be a couple, or a few, unused system accounts, which doesn't seem to be much of a cost. People who want to take the risk can change the default. I would prefer to have this put into a separate command that can be called from a postrm script, rather than as a debhelper command. Not all packages use debhelper, and, anyway, a separate tool can be more easily fixed without having to rebuild lots of packages. -- Without grand dreams, how can you save the world? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Authentication [Was: Bits from the release team: the plans for etch]
Hello everyone, following all the discussion about when to add or remove users/groups and when to do this, i must that maybe some work is done (not using the standard adduser commands but almost). I package libuser (from RH). From the Description: The libuser library implements a standardized interface for manipulating and administering user and group accounts. The library uses pluggable back-ends to interface to its data sources. It already has backends for ldap, kerberos, standard Unix password/shadow and sasldb. Modules for NIS are planned. Configuring properly the backends one can add/remove users/groups from them. There are also some examples programs that extends its functionality. Apart of this, some time ago, i take a look to authconfig, the RH (again) utility to configure (ncurses and gtk available) the workstations to authenticate locally, via kerberos, ldap, heisod... Almost all the code was vendor independent and the only changes necessary were those related to the organization of pam configuration. I filled a ITP some time ago and it's almost working. It somebody want to sponsor it, we can upload it to experimental and start the party. Ghe Rivero -- CPD - Universidad Pontificia de Salamanca Tlf. 923 277 136 - Ext. 7263 .''`. Pienso, Luego Incordio : :' : `. `' Proudly running Debian GNU/Linux (Sid 2.6.9-smp Ext3) `-www.debian.orgwww.upsa.es GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Wed, Oct 26, 2005 at 08:44:12AM -0700, Thomas Bushnell BSG wrote: One cannot guarantee that the local admin hasn't used the account for other things as well. Please read. We cannot guarantee that an admin fiddles with binaries in /usr/bin/ (as opposed to /usr/local/bin) either. That doesn't mean that packages have to cope with that situation. But chowning files to match a system account is not some weird thing that we can't expect.
Re: Bits from the release team: the plans for etch
Humberto Massa [EMAIL PROTECTED] writes: Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. And what bad results does this produce? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Stephen Frost [EMAIL PROTECTED] writes: * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: I disagree with the idea that removing a user is a bug. If the user was added by the package, and the package is being purged, and there's a reasonable expectation that it wasn't used outside of the package's use of it then I think it's probably safe to remove it. How do you acquire that expectation? By knowing what the package uses the user for. This is somewhat akin to the PostgreSQL package's question do you want your data files to be purged upon package removal, or the fact that the default Postgres installation uses ident and the 'postgres' user is the superuser for the database (meaning you're going to be su'ing to postgres probably a fair bit). How do you know that the system administrator hasn't chowned a file to that UID? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Humberto Massa [EMAIL PROTECTED] writes: Problem being, if daemons don't remove their (supposedly exclusive-use) accounts, you can end in two years with 100 unnecessary accounts in a workstation. And what bad results does this produce? A dependency on 'lock-out' mechanisms that may or may not work as well as one might hope. I'm more inclined towards the idea of keeping a system-user counter so as to avoid reuse of the same uids, though I'm not convinced that's actually necessary. Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: By knowing what the package uses the user for. This is somewhat akin to the PostgreSQL package's question do you want your data files to be purged upon package removal, or the fact that the default Postgres installation uses ident and the 'postgres' user is the superuser for the database (meaning you're going to be su'ing to postgres probably a fair bit). How do you know that the system administrator hasn't chowned a file to that UID? Same way you know that the system administrator hasn't modified a file in /usr/bin. Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
Stephen Frost [EMAIL PROTECTED] writes: * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: By knowing what the package uses the user for. This is somewhat akin to the PostgreSQL package's question do you want your data files to be purged upon package removal, or the fact that the default Postgres installation uses ident and the 'postgres' user is the superuser for the database (meaning you're going to be su'ing to postgres probably a fair bit). How do you know that the system administrator hasn't chowned a file to that UID? Same way you know that the system administrator hasn't modified a file in /usr/bin. Um, I know that by comparing the contents against a known-true version. How do I detect whether the system administrator has used a UID? Moreover, the consequences of getting the one wrong are that you delete the sysadmin's changes. The consequences of the other are an important and difficult-to-detect security hole. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Same way you know that the system administrator hasn't modified a file in /usr/bin. Um, I know that by comparing the contents against a known-true version. How do I detect whether the system administrator has used a UID? Except last I checked, we don't do such comparison. If you really wanted to know if the UID was used you could do a find /, etc. Neither is necessary though, which is the point. Moreover, the consequences of getting the one wrong are that you delete the sysadmin's changes. The consequences of the other are an important and difficult-to-detect security hole. This is just patently false, as has been pointed out elsewhere. What security hole, exactly, is created by orphaning a file? Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]: * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Same way you know that the system administrator hasn't modified a file in /usr/bin. Um, I know that by comparing the contents against a known-true version. How do I detect whether the system administrator has used a UID? Except last I checked, we don't do such comparison. If you really wanted to know if the UID was used you could do a find /, etc. Neither is necessary though, which is the point. Moreover, the consequences of getting the one wrong are that you delete the sysadmin's changes. The consequences of the other are an important and difficult-to-detect security hole. This is just patently false, as has been pointed out elsewhere. What security hole, exactly, is created by orphaning a file? Well, if some process (maybe within the package) creates a private log file that contains sensitive information, and this log file can later on be read by a process with much less privileges, this is usually considered as security relevant issue. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Andreas Barth ([EMAIL PROTECTED]) wrote: * Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]: This is just patently false, as has been pointed out elsewhere. What security hole, exactly, is created by orphaning a file? Well, if some process (maybe within the package) creates a private log file that contains sensitive information, and this log file can later on be read by a process with much less privileges, this is usually considered as security relevant issue. Except log files are supposed to be removed and I don't know of any actual case of this happening anyway. Additionally, this is *not* a problem with the orphaning of the file, it's a problem with the reuse of a previously-used uid. I could see adding a system to track previously-used uids and not reusing them. I don't believe using passwd for that (and keeping unused accounts in passwd/shadow/group/gshadow/etc) is appropriate. It would seem enough to me, at least, to keep an ever-increasing counter where the current value is the next available uid. This could be reset if it reaches the max, or an error presented to the user about it or some such. I'm not convinced that's necessary but I could see it being something reasonable to do. Just leaving around unused accounts isn't reasonable. Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:46]: Additionally, this is *not* a problem with the orphaning of the file, it's a problem with the reuse of a previously-used uid. I could see adding a system to track previously-used uids and not reusing them. I don't believe using passwd for that (and keeping unused accounts in passwd/shadow/group/gshadow/etc) is appropriate. It would seem enough to me, at least, to keep an ever-increasing counter where the current value is the next available uid. This could be reset if it reaches the max, or an error presented to the user about it or some such. Well, I could see us to build such a system. But this system isn't there - and IMHO the next working way to prevent uids of being reused is to keep the account in question (perhaps locked etc, as suggested elsewhere). Anything else is IMHO plainly broken. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Andreas Barth ([EMAIL PROTECTED]) wrote: * Stephen Frost ([EMAIL PROTECTED]) [051026 20:46]: Additionally, this is *not* a problem with the orphaning of the file, it's a problem with the reuse of a previously-used uid. I could see adding a system to track previously-used uids and not reusing them. I don't believe using passwd for that (and keeping unused accounts in passwd/shadow/group/gshadow/etc) is appropriate. It would seem enough to me, at least, to keep an ever-increasing counter where the current value is the next available uid. This could be reset if it reaches the max, or an error presented to the user about it or some such. Well, I could see us to build such a system. But this system isn't there - and IMHO the next working way to prevent uids of being reused is to keep the account in question (perhaps locked etc, as suggested elsewhere). Anything else is IMHO plainly broken. Leaving around unused accounts is plainly wrong too, and also a potential security risk. If we're going to try to push for a broad change in how this is handled then let's do it the *right* way by creating such a system as I described above, not by breaking the system to leave unused accounts around. Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 02:58:15PM -0400, Stephen Frost wrote: Leaving around unused accounts is plainly wrong too, and also a iyho. potential security risk. If we're going to try to push for a broad change in how this is handled then let's do it the *right* way by or, how about we not push for a broad change at all? sean signature.asc Description: Digital signature
Removing system users on purge [Re: Bits from the release team: the plans for etch]
On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote: On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote: What about log files with sensitive content? Non-issue, as I said in the end of my post, those should be removed on purge. The log files that are created by the default package configuration should be removed, but custom modifications to the configuration can cause logfiles to be created elsewhere that are owned by the user in question. Case reopened. Don Armstrong -- UF: What's your favourite coffee blend? PD: Dark Crude with heavy water. You are understandink? If geiger counter does not click, the coffee, she is just not thick. http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Bits from the release team: the plans for etch
* sean finney ([EMAIL PROTECTED]) wrote: On Wed, Oct 26, 2005 at 02:58:15PM -0400, Stephen Frost wrote: Leaving around unused accounts is plainly wrong too, and also a iyho. Duh? I ain't humble tho. :) potential security risk. If we're going to try to push for a broad change in how this is handled then let's do it the *right* way by or, how about we not push for a broad change at all? Wasn't my idea. :) I expect there will be additional claims that the current situation creates 'security holes' though. I don't buy it, personally, but that's the claim. Thanks, Stephen signature.asc Description: Digital signature
Re: Removing system users on purge [Re: Bits from the release team: the plans for etch]
* Don Armstrong ([EMAIL PROTECTED]) wrote: On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote: On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote: What about log files with sensitive content? Non-issue, as I said in the end of my post, those should be removed on purge. The log files that are created by the default package configuration should be removed, but custom modifications to the configuration can cause logfiles to be created elsewhere that are owned by the user in question. Have we actually got a specific case of this happening and there being a real security threat from it? Seems like an aweful lot of hand-waving and concern for a possible scenario that doesn't seem to have actually happened much (if it all, so far all I've seen has been pure speculation). An admin can set root's password to 'password' and allow remote root login too, and that probably happens with greater frequency than the scenario being put forth here. Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
Stephen Frost wrote: * Andreas Barth ([EMAIL PROTECTED]) wrote: * Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]: This is just patently false, as has been pointed out elsewhere. What security hole, exactly, is created by orphaning a file? Well, if some process (maybe within the package) creates a private log file that contains sensitive information, and this log file can later on be read by a process with much less privileges, this is usually considered as security relevant issue. Except log files are supposed to be removed and I don't know of any actual case of this happening anyway. Additionally, this is *not* a problem with the orphaning of the file, it's a problem with the reuse of a previously-used uid. I could see adding a system to track previously-used uids and not reusing them. I don't believe using passwd for that (and keeping unused accounts in passwd/shadow/group/gshadow/etc) is appropriate. It would seem enough to me, at least, to keep an ever-increasing counter where the current value is the next available uid. This could be reset if it reaches the max, or an error presented to the user about it or some such. I'm not convinced that's necessary but I could see it being something reasonable to do. Just leaving around unused accounts isn't reasonable. one (more interesting, maybe) approach could be using some automated method to see what are _every_ _single_ user-id created by our packages (not very difficult) and collecting them in a single package, with UNIQUE uids (so www-data will be , no matter what): this way we can purge users at --purge time. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:58]: Leaving around unused accounts is plainly wrong too, and also a potential security risk. I'm certain you can proof this. If we're going to try to push for a broad change in how this is handled then let's do it the *right* way by creating such a system as I described above, Feel free to implement such a system. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Stephen Frost [EMAIL PROTECTED] writes: * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Same way you know that the system administrator hasn't modified a file in /usr/bin. Um, I know that by comparing the contents against a known-true version. How do I detect whether the system administrator has used a UID? Except last I checked, we don't do such comparison. If you really wanted to know if the UID was used you could do a find /, etc. Neither is necessary though, which is the point. So what? My point is that it is not *possible* to determine that a uid hasn't been used for some unexpected purpose. You said we should reuse the uid if it hasn't been so used. Are you now saying that we should reuse it and not try to figure out at all? Find on / of course doesn't work. Well, it works if you never make backups or use removable media. Uh huh. Moreover, the consequences of getting the one wrong are that you delete the sysadmin's changes. The consequences of the other are an important and difficult-to-detect security hole. This is just patently false, as has been pointed out elsewhere. What security hole, exactly, is created by orphaning a file? The UID gets reused, and the new possessor of the UID suddenly owns the old files. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Stephen Frost [EMAIL PROTECTED] writes: * Andreas Barth ([EMAIL PROTECTED]) wrote: * Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]: This is just patently false, as has been pointed out elsewhere. What security hole, exactly, is created by orphaning a file? Well, if some process (maybe within the package) creates a private log file that contains sensitive information, and this log file can later on be read by a process with much less privileges, this is usually considered as security relevant issue. Except log files are supposed to be removed and I don't know of any actual case of this happening anyway. We aren't talking about log files created by the package, but by the sysadmin. What if the sysadmin has taken the sensitive log and squirreled it away, saving it for future reference? Is that no longer a supported thing? Additionally, this is *not* a problem with the orphaning of the file, it's a problem with the reuse of a previously-used uid. I could see adding a system to track previously-used uids and not reusing them. I don't believe using passwd for that (and keeping unused accounts in passwd/shadow/group/gshadow/etc) is appropriate. Why? What purpose is served by segregating the information? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Stephen Frost [EMAIL PROTECTED] writes: Leaving around unused accounts is plainly wrong too, and also a potential security risk. Can you outline the risk please? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing system users on purge [Re: Bits from the release team: the plans for etch]
Stephen Frost [EMAIL PROTECTED] writes: Have we actually got a specific case of this happening and there being a real security threat from it? Seems like an aweful lot of hand-waving and concern for a possible scenario that doesn't seem to have actually happened much (if it all, so far all I've seen has been pure speculation). There isn't any particular reason I can see for wanting to remove the old id's from /etc/passwd. Nothing concrete has been proposed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Leaving around unused accounts is plainly wrong too, and also a potential security risk. Can you outline the risk please? Sure. Locking accounts isn't necessairly perfect. Checking that an account is locked requires going through more of the authentication system than just checking if the account exists. What happens if an admin gives a password to a system account and then forgets about the account after purging the software it's associated with? Not everything which does authentication using /etc/passwd checks /etc/shells. Some authentication systems don't use passwords too (Kerberos). Not everything on the system uses PAM and may not follow the same account-locking rules as PAM. Even sudo scripts left around might cause problems if the account still exists, where if the account just didn't exist the sudo script would fail from the get-go. Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: We aren't talking about log files created by the package, but by the sysadmin. What if the sysadmin has taken the sensitive log and squirreled it away, saving it for future reference? Is that no longer a supported thing? One would hope he'd chown it too. Indeed, *most* log files are owned by root/adm anyway. I'd actually be happier if that could be enforced, thus this concern about log files actually goes away, not that I think it's really a legitimate concern anyway. Additionally, this is *not* a problem with the orphaning of the file, it's a problem with the reuse of a previously-used uid. I could see adding a system to track previously-used uids and not reusing them. I don't believe using passwd for that (and keeping unused accounts in passwd/shadow/group/gshadow/etc) is appropriate. Why? What purpose is served by segregating the information? Not keeping around unused accounts, that may have been set up as capable of being authenticated to in the past by the admin for whatever reason. Not to mention that it's leaving a hell of alot more around than is necessary. If you don't want to reuse ids, then have a nice simple system that prevents reusing them, don't leave cruft around to get in the way to try and prevent it. What happens when the piece of software that created the userid initially is reinstalled? What if the attributes for the user changed, possibly to deal with some security flaw in the original configuration? What if there were files still on the system that the new installation *shouldn't* have access to? Even better, what if that crazy admin created orphaned files to *begin* with, and didn't put a user in /etc/passwd, whoops! We create a new user with that userid, oh no, big security hole... Thanks, Stephen signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
On Wed, Oct 26, 2005 at 06:29:57PM +0200, Andreas Barth wrote:
Problem being, if daemons don't remove their (supposedly exclusive-use)
accounts, you can end in two years with 100 unnecessary accounts in a
workstation.
How many daemon packages do you install in two years? I even doubt that
we have 100 packages that add accounts at all in debian.
Sorry, you'll have to clear up your facts first. How about doing this:
{
lynx -dump -nolist \
http://lintian.debian.org/reports/Tmaintainer-script-needs-depends-on-adduser.html
| \
perl -ne 'print $1.\n if /W: (.*?): /'
grep-available -sPackage -FPre-Depends,Depends adduser | awk '{print $2}'
} | wc -l
( I already posted this recipe in the thread, BTW )
That's 187 packages by my count, and might not cover all cases. Now, we have
a limit of 400 system uids in our current setting (499-100+1, see
adduser.conf) and, from what I'm seeing as part of my security audit work,
*many* *more* packages should be creating system users to run daemons as
low-priviledged users instead of running as root.
So, over 100 currently, and not an issue right now but might be in the future.
Javier
signature.asc
Description: Digital signature
Re: Bits from the release team: the plans for etch
This one time, at band camp, Javier Fernández-Sanguino Peña said: On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote: On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: Creating system users needs to cope with the fact that users might have greated them before hand. adduser copes with that. If a system user to be created does already exist with the required properties, adduser is a no-op and exists with a zero exit code. If a system user to be created does already exist with different attributes, it exists with non-zero exit code, as this is an error. And that's something that packages maintainer scripts have to cope with since they don't know beforehand if it's there and it certainly doe snot have the same attirbutes (it might only share the name) While I appreciate the effort at a standard shell script fragment for 'install a user', and think that it would be useful as reference and for reuse, I tend to think making it a dh_ fragment doesn't work in the normal use cases I can think of. Ordinarily, when a package installs a user, the logic of the maintainer script goes something like: add user chown a bunch of stuff to the new user start the daemon Correct me if I'm wrong, but I'm imagining this dh_ fragment being added by the DEBHELPER blob at the end, and so anything needed to be done in between adding the user and starting the daemon (the other common and useful debhelper fragment in this sort of case) kind of blows up. Unless I'm missing the way you were going to implement this. But, seriously, it does sound like a useful reference piece, even if it can't be added automatically. If it can, so much the better. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bits from the release team: the plans for etch
Stephen Frost [EMAIL PROTECTED] writes: * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Leaving around unused accounts is plainly wrong too, and also a potential security risk. Can you outline the risk please? Sure. Locking accounts isn't necessairly perfect. What is an account in the password file? It's nothing more than the ability to log in under a given UID. How is a starred password anything other than perfect locking of the account? Checking that an account is locked requires going through more of the authentication system than just checking if the account exists. What happens if an admin gives a password to a system account and then forgets about the account after purging the software it's associated with? The same thing that happens if he creates a setuid program using that UID. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
