On Sat, 2007-10-20 at 04:32 +0000, Duncan wrote: > > It would be a Good Thing if new local accounts could be added to group > > plugdev when they're created.
This is mostly just wishful thinking. There are a number of groups that a desktop user should be added to, depending on what's to be done with the system. I quite agree with you in general on the security issue, when I think about it, but not if the box is a single-user desktop system. > Adding users you wish to have this access to the plugdev group is indeed > the correct solution, and indeed, mentioned in the log messages for the > hal package when you merge it. Check your portage messages log, or see > the elog at the end of the hal ebuilds if necessary. So the instructions > were there for you to read if you wanted to. Gentoo does its best with the portage log messages, and has improved recently, and I actually helped write the enotice utility that some people use to read these things. The bottom line, however, is that it's still an very inconvenient format for essential documentation. Your comment is a bit like saying that the instructions for the tool you just bought are pasted to the inside of the shipping carton, and, well, if you don't understand how it works, just RTFM ;-) On top of this, there was nothing in the error message I got to positively identify this problem as as Hal issue any more than a Dbus issue. The error box text said to see the Dbus config file, which really didn't help much. The Gentoo spec for package metadata (metadata.xml) contains a virtually unused field, <longdescription>, which could easily be used to contain tidbits of this sort. I've lobbied on Gentoo bugzilla to have this field used more constructively for this sort of information, but didn't get anywhere. One could have emerege or better, equery be able to pull up this info per package. The down side, of course, is that it would increase the size of the portage tree, but the essential information is already being stored in the ebuilds and is output to a running log that can be many megs long and not designed to be searchable. > However, security-wise, you've hit a bit of a raw nerve here, so excuse > me while I rant a bit... You're excused ;-) > It would *NOT* be a "Good Thing" (r), and in fact, would be a very "Bad > Thing" (r) to do this automatically when new users are created, as that > kills important aspects of the Unix/Linux security model, the entire > reason the generic "users" group isn't used in the first place. There > are good reasons sysadmins may not WANT every user to have automount > rights, and it's already possible to expand your newuser scripts locally > to automatically add a user to various groups, if you as sysadmin decide > that's what you want to do. I think one of the problems we have as sysadmins is that we often fail to distinguish between the security model required for a classic Unix multi-user system and a Linux desktop box which probably runs on a private network with probably only one or two users who are logged on sequentially rather than simultaneously. In the former case, you're quite right. I've been seriously rethinking the matter of security for the latter case. > So... please think before you make requests for automating procedures > that effectively automate the creation of security holes. If you want > platforms that do such things, they are available; no need to make Gentoo > into one of them by default. If I'd seriously wanted to make a request, I'd have filed an enhancement request on Gentoo bugzilla, and indeed I would have given it a good deal more thought. This was not so much a request here as an aside, thinking that there needs to be some documentation format more convenient than e.g. fishing through portage logs for finding out how to properly tweak a user account on a desktop system in order to get it to work properly with various facilities on the host box. -- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | | -- [EMAIL PROTECTED] mailing list
