Cleaning up the users and locking down the shells in /etc/passwd
Hi! Would it be possible to remove the vast majority of users from /etc/passwd and instead rely on the application being installed to create the specific user if needed? Most of the users appear to be historical remnants that have been carried over from release to release. In addition, for users in the passwd file that must be there, could you please set their shell to /usr/sbin/nologin? Thanks for considering this! ~Matt -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Sat, Sep 24, 2011 at 9:48 AM, Colin Watson wrote: > On Thu, Sep 22, 2011 at 04:33:00PM -0700, Matt Alexander wrote: > > Would it be possible to remove the vast majority of users from > /etc/passwd > > and instead rely on the application being installed to create the > specific > > user if needed? Most of the users appear to be historical remnants that > > have been carried over from release to release. > > For almost everything, and certainly for the overwhelming majority of > new entries, we do exactly as you say. However, I (as base-passwd > maintainer) will not remove entries from the global static list unless > there is a very compelling reason to do so beyond cleaning up cruft; > packages are entitled to assume that they are present without declaring > any particular dependency and there's no reasonable way to know what > removing such entries would break. > I end up modifying the passwd/group files on my computers for auditing purposes and to ensure that the only accounts on the system are required accounts. Removing cruft seems like a perfectly valid reason. In 10 years will Ubuntu still have a uucp user and a news user and an irc user? Seems silly. Let's clean things up and keep it to just the accounts that must be there. We can then easily fix packages that wrongly assumed that their particular user would be always be there. > > In any case, there are only 18 entries in the global static list > (/usr/share/base-passwd/passwd.master), and even without thinking about > it too hard I know that at least four or five are still in use and > probably more, so there's not that much to be gained. All other system > entries in the passwd file are created dynamically by applications. > > Since I took over base-passwd in 2002, I have added no new global static > users and only two new global static groups, the last of which was in > 2004. > > > In addition, for users in the passwd file that must be there, could you > > please set their shell to /usr/sbin/nologin? > > Yes, I would like to do this eventually > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274229). However, > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184979 has to be fixed > first, otherwise everyone will have their upgrades interrupted by a > non-debconf prompt. I haven't had time to work on #184979 in quite a > number of years, and to the best of my knowledge nobody has ever > contributed a patch for it; I'd be happy to review one if somebody did > so. > > The one wart here is that using /usr/sbin/nologin will break anything > that runs commands as one of those users using the 'su' command. This > isn't theoretical; one of my packages used to do so some years ago, > although it now uses start-stop-daemon instead. The breakage is > probably worthwhile, I'll admit, but I can't say that there would be no > problems with changing those users' shell since there's been such a long > time for packages to get used to it being /bin/sh. > > Cheers, > > -- > Colin Watson [cjwat...@ubuntu.com] > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Mon, Sep 26, 2011 at 3:28 PM, Bear Giles wrote: > Matt, why not create a hardening package? Just write a script that scrubs > /etc/passwd and /etc/group and then create a small package that runs it once > (in postinst). I would also install it in, e.g., /etc/cron.daily so it's > rerun periodically. I haven't kept track of existing hardening packages > but I wouldn't be surprised if somebody else has already done this. I've used Bastille in the past, for example, but I think most users would prefer that Ubuntu is already hardened by default. > > P.S., if you want to have fun with package installation failing try > mounting /tmp as noexec. It's easy to fix - if you know how to do it. If not > you'll bang your head against the wall for hours while you're trying to > figure out why installations are failing. > > bear > > > On Mon, Sep 26, 2011 at 4:05 PM, Matt Alexander < > ubuntu@mattalexander.com> wrote: > >> On Sat, Sep 24, 2011 at 9:48 AM, Colin Watson wrote: >> >>> On Thu, Sep 22, 2011 at 04:33:00PM -0700, Matt Alexander wrote: >>> > Would it be possible to remove the vast majority of users from >>> /etc/passwd >>> > and instead rely on the application being installed to create the >>> specific >>> > user if needed? Most of the users appear to be historical remnants >>> that >>> > have been carried over from release to release. >>> >>> For almost everything, and certainly for the overwhelming majority of >>> new entries, we do exactly as you say. However, I (as base-passwd >>> maintainer) will not remove entries from the global static list unless >>> there is a very compelling reason to do so beyond cleaning up cruft; >>> packages are entitled to assume that they are present without declaring >>> any particular dependency and there's no reasonable way to know what >>> removing such entries would break. >>> >> >> I end up modifying the passwd/group files on my computers for auditing >> purposes and to ensure that the only accounts on the system are required >> accounts. Removing cruft seems like a perfectly valid reason. In 10 years >> will Ubuntu still have a uucp user and a news user and an irc user? Seems >> silly. Let's clean things up and keep it to just the accounts that must be >> there. We can then easily fix packages that wrongly assumed that their >> particular user would be always be there. >> >> >> >>> >>> In any case, there are only 18 entries in the global static list >>> (/usr/share/base-passwd/passwd.master), and even without thinking about >>> it too hard I know that at least four or five are still in use and >>> probably more, so there's not that much to be gained. All other system >>> entries in the passwd file are created dynamically by applications. >>> >>> Since I took over base-passwd in 2002, I have added no new global static >>> users and only two new global static groups, the last of which was in >>> 2004. >>> >>> > In addition, for users in the passwd file that must be there, could you >>> > please set their shell to /usr/sbin/nologin? >>> >>> Yes, I would like to do this eventually >>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274229). However, >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184979 has to be fixed >>> first, otherwise everyone will have their upgrades interrupted by a >>> non-debconf prompt. I haven't had time to work on #184979 in quite a >>> number of years, and to the best of my knowledge nobody has ever >>> contributed a patch for it; I'd be happy to review one if somebody did >>> so. >>> >>> The one wart here is that using /usr/sbin/nologin will break anything >>> that runs commands as one of those users using the 'su' command. This >>> isn't theoretical; one of my packages used to do so some years ago, >>> although it now uses start-stop-daemon instead. The breakage is >>> probably worthwhile, I'll admit, but I can't say that there would be no >>> problems with changing those users' shell since there's been such a long >>> time for packages to get used to it being /bin/sh. >>> >>> Cheers, >>> >>> -- >>> Colin Watson [cjwat...@ubuntu.com] >>> >>> -- >>> Ubuntu-devel-discuss mailing list >>> Ubuntu-devel-discuss@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >>> >> >> >> -- >> Ubuntu-devel-discuss mailing list >> Ubuntu-devel-discuss@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >> >> > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Tue, Sep 27, 2011 at 1:28 AM, Colin Watson wrote: > On Mon, Sep 26, 2011 at 03:05:58PM -0700, Matt Alexander wrote: > > On Sat, Sep 24, 2011 at 9:48 AM, Colin Watson > wrote: > > > For almost everything, and certainly for the overwhelming majority of > > > new entries, we do exactly as you say. However, I (as base-passwd > > > maintainer) will not remove entries from the global static list unless > > > there is a very compelling reason to do so beyond cleaning up cruft; > > > packages are entitled to assume that they are present without declaring > > > any particular dependency and there's no reasonable way to know what > > > removing such entries would break. > > > > I end up modifying the passwd/group files on my computers for auditing > > purposes and to ensure that the only accounts on the system are required > > accounts. Removing cruft seems like a perfectly valid reason. In 10 > years > > will Ubuntu still have a uucp user and a news user and an irc user? > Seems > > silly. Let's clean things up and keep it to just the accounts that must > be > > there. We can then easily fix packages that wrongly assumed that their > > particular user would be always be there. > > I'm afraid this is backwards. If you want to go and hunt down packages > that rely on those global static users and get their maintainers > (preferably in Debian) to work on a migration to dynamically-allocated > system users, perhaps after that it would be worth removing the global > static users. Until then, they need to stay where they are. > Seems like detecting broken packages from system changes would already be part of the Ubuntu qual. process. But, OK, I'll setup a box, remove users, and run a script that installs/uninstalls everything one by one from the default repos and makes note of any packages that break. I'll then open bugs with the Debian maintainers of those packages to modify their install/uninstall script. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Tue, Sep 27, 2011 at 8:06 AM, Colin Watson wrote: > On Tue, Sep 27, 2011 at 06:12:24AM -0700, Matt Alexander wrote: > > On Tue, Sep 27, 2011 at 1:28 AM, Colin Watson > wrote: > > > I'm afraid this is backwards. If you want to go and hunt down packages > > > that rely on those global static users and get their maintainers > > > (preferably in Debian) to work on a migration to dynamically-allocated > > > system users, perhaps after that it would be worth removing the global > > > static users. Until then, they need to stay where they are. > > > > Seems like detecting broken packages from system changes would already be > > part of the Ubuntu qual. process. > > It's always better to not break things in the first place. > Sometimes breaking things is necessary for forward progress. > > > But, OK, I'll setup a box, remove users, and run a script that > > installs/uninstalls everything one by one from the default repos and > > makes note of any packages that break. I'll then open bugs with the > > Debian maintainers of those packages to modify their install/uninstall > > script. > > Sounds great, thanks! > > Note that I will not remove these users in any event: > > root (obviously) > daemon (required by LSB) > bin (required by LSB) > sync (specialised, described in users-and-groups documentation) > games (shared among many packages, likely to be too disruptive) > man (man-db is widely installed anyway so any gain is not worth it) > mail (often has many non-system-owned files, too disruptive) > www-data (often has many non-system-owned files, too disruptive) > nobody (obviously) > > You can refer to /usr/share/doc/base-passwd/users-and-groups.txt.gz for > what's known about various system users. > > Great info. Thanks! -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Moving all binaries to /usr/bin ?
Interesting proposed change for the location of binaries in Fedora: http://www.h-online.com/open/news/item/Fedora-considers-moving-all-binaries-to-usr-bin-1369642.html Would Ubuntu consider doing the same? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Unity and Classic
On Thu, Dec 1, 2011 at 7:33 AM, Shane Fagan wrote: > On Thu, Dec 1, 2011 at 1:25 PM, Ronan Lucio wrote: > > Hi Carlos, > > > > I'm not sure about it. > > I know there are so many users prefering the old gnome style. > > > > I think the best option would be a simple way to config which interface > the > > users prefers, like on 11.04 version. > > So the user could choice between Unity, Gnome3 or Gnome-Fallback > (Classic) > > > > But it think this option must exists for all Ubuntu versions. > > There is an option just install gnome classic. Splitting our efforts > helps no one and pulls resources away from making Ubuntu keep up with > what Windows 8 is going to be doing. Id say if you don't like > something in Unity you should share your experience and preference and > see if there is something more we could be doing just saying I don't > like it doesn't really help anyone understand why you don't like it. > I don't like it because I can't find the most common apps anymore. I used to be able to navigate through the Applications menu using general categories like Graphics, Games, Sound & Video, etc. Now I stare blankly at a dialog box that expects me to have memorized every app name that I might use and I have to TYPE THAT COMMAND LINE NAME IN. WTF. That's a terrible user experience. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Unity and Classic
On Thu, Dec 1, 2011 at 8:28 AM, Sebastien Bacher wrote: > Le 01/12/2011 17:11, Matt Alexander a écrit : > > >> I don't like it because I can't find the most common apps anymore. I >> used to be able to navigate through the Applications menu using general >> categories like Graphics, Games, Sound & Video, etc. >> > > Is the issue there only the number of click to display the application > lens with the installed applications not reduced to the default 1 line and > with the filters on the side? This cycle Unity should make it things a bit > easier there by: > - letting you add lenses icons directly to the launcher, if you access > often the application one you could get it there > - remember some of the dash settings cross sessions > > Would you be happy with the application lens if it opened directly from > the launcher with filters already on screen and the list unfolded for you? > I'm not sure what "application lens" means. When I click the Ubuntu icon, I get a full screen of 8 icons. Let's say I'm interested in that Brain game that I used to play on 10.04, but can't remember what the actual name was. So I type "brain". I get an empty page back. Hmm, OK, well, let's try something else. How do I get back? I have to click the Ubuntu icon twice. The first makes the blank results page go away. The second brings back the default 8 icons. I then click "More Apps". Hmm, it's not in the short displayed list of apps. I then click the tiny text that says, "See 89 more results" and scroll through lots of apps until I find the "brain" icon that I remember from 10.04. That's quite a bit of work compared to 10.04. I totally missed the "Filter results" option before. If that list of categories was available after clicking the Ubuntu icon, then I'd be happy. I could then simply go Ubuntu icon -> Games -> gbrainy. Another idea... let's say I want to use gimp (and it's not installed yet), so I type in "gimp" into the search box. Instead of a confusing blank page, provide a link to install the gimp package. Thanks for considering this. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu should move all binaries to /usr/bin/
Sure, using find or which, etc., can be used to locate a particular app, but that's not really the point. Why not simplify things and put all binaries under /usr/bin? Then you don't have to teach users about silly distinctions like "Oh, see, if it's an app that's meant to be used by a System Adminstrator, then it goes into /usr/sbin". Who cares? Just put everything in /usr/bin to keep things simple. On Mon, Dec 5, 2011 at 4:24 AM, Dane Mutters wrote: > I don't know if the original poster has since learned this, but I think > it's worth noting several things, in case the person coming over from > Windows hasn't figured it out. (If this is a non-issue, please disregard > this email.) > > 1) Linux/Unix executables don't have a .exe extension. Typically, they > don't have any extension at all, and can conceivably have every extension > imaginable (including common ones like .sh for scripts). If you're looking > for an executable, forget looking for its extension. Try using the "find" > command to look for executable files, or if you know the one you want, > already, use the "which" command, as above. > > 2) You almost certainly don't need to find that file. As mentioned above, > if it's not in your PATH setting, then something is broken. This is pretty > rare. If you need to execute a command--from a terminal or from an "open > with" dialogue, just type the command (in the appropriate dialogue box, as > needed). If you want to open a PDF, and the GUI hasn't figured out how to > do that, type "acroread", "evince", or whatever you have installed into the > box. > > 3) +1 about Windows having an absurdly hard-to-use filesystem, > where finding binaries/executables is concerned. Once you learn Linux, > you'll bless its build-in filesystem, and probably find little/no need to > mess with it. For that matter, +1 to all the stuff about /bin, /sbin, > /usr/local/bin, /usr/local/sbin, /opt, etc. having useful, specific > purposes. Sure, it bugs me when some program insists on installing > someplace I don't think makes sense. Usually it'll let me change it upon > install, if it's from a script, but if not, I can still put it into the > PATH if it's not already there, and after that it doesn't matter! So long > as the uninstall functionality works for a given program (which it REALLY, > REALLY should...), and the executable structure of the program is remotely > sensible (looking at you, OpenOffice, Mozilla, etc.), it's all gravy, so > far as I'm concerned. Proprietary programs are the more problematic > culprits, anyway, and there's not much a distribution can do about them, so > far as I'm aware. > > 4) I've never liked Fedora, anyway. :-p > > > I'm sure the real gurus here know a lot more about the specifics than I > do, so have at it! > > --Dane > > > On Mon, Nov 7, 2011 at 3:16 AM, Colin Watson wrote: > >> On Sat, Nov 05, 2011 at 02:40:31AM +0800, John McCabe-Dansted wrote: >> > We could even enhance which to look in obvious places off the path >> (perhaps >> > locatedb?) and print the output on stderr if we really wanted to. >> >> Please don't - 'which' is used in scripts and needs to preserve its >> current behaviour. Any extra behaviour should be added to a >> different/new program. >> >> -- >> Colin Watson [cjwat...@ubuntu.com] >> >> -- >> Ubuntu-devel-discuss mailing list >> Ubuntu-devel-discuss@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >> > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu should move all binaries to /usr/bin/
On Mon, Dec 5, 2011 at 5:22 PM, Robert Holtzman wrote: > On Mon, Dec 05, 2011 at 09:15:11AM -0800, Matt Alexander wrote: > > Sure, using find or which, etc., can be used to locate a particular app, > > but that's not really the point. Why not simplify things and put all > > binaries under /usr/bin? Then you don't have to teach users about silly > > distinctions like "Oh, see, if it's an app that's meant to be used by a > > System Adminstrator, then it goes into /usr/sbin". Who cares? Just put > > everything in /usr/bin to keep things simple. > > There are programs that an admin doesn't want users to run. > You're kidding, right? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
