On Sat, Jan 13, 2007 at 04:27:11AM EST, Andrei Popescu wrote: > On Fri, 12 Jan 2007 21:28:50 -0500 > cga2000 <[EMAIL PROTECTED]> wrote: > > > first of all you have to remember that: > > > > # usermod -G adm myuser > > > > .. wipes out all your other groups .. so you have to try and figure > > out what groups you were in (or restore from a backup) .. and then > > issue a: > > > > # usermod -G adm,grp1,grp2,grp3 myuser > > > > .. don't leave out the commas between the groups..! > > > > then every time you want to actually view the logs you have to issue > > a: > > > > $ newgrp adm > > Why not simply use 'adduser myuser newgroup'?
Because the adduser/addgroup man page starts with these words: "add a user or group to the system". So I thought .. well that's not it then .. and then I eventually stumbled upon "usermod -G" whose name makes a lot more sense since you are modifying an already existing user. I can see now that 117 lines down into the adduser man page (on my display) there is a brief mention of the fact that "If called with two non-option arguments, adduser will add an existing user to an existing group." What's rather irritating is that I have a feeling of deja vous about this. I kind of remember that I ran into this same problem three years ago, maybe .. and wasted an inordinate amount of time playing with usermod trying to find a sensible way to add myself to a couple of groups thinking all the time.. why .. oh why does this have to be so messy .. before I found out (quite by accident) that you could/should use adduser instead. To further add to the confusion, there is also a "useradd" command that uses the "G" flag the way usermod does. Reminds me of those high-end eateries with about half a dozen forks and knives staring at you and your food is already cold by the time you're done debating which ones you're supposed to use. In any case this does not address the main annoyance of having to use newgrp to switch groups. I'd much rather stick with my policy of running an su root session on the side for times when I can't find a sensible way to do things off of my personal id. > > I use cdrecord. > > > > But the problem is that my burner is defined like so: > > > > crw------- 1 root root 21, 0 2002-08-29 18:00:48.-0400 /dev/sg0 > > > > So only root has access to it. Mind you I could chown it over to my > > user .. or change the group to cdrom and give it group rw > > permissions. The trouble about this approach that all these little > > changes add up and I tend to forget these things. Some way or other > > I suspect this'd come back and bite me when I least expect it. And > > then with this strategy I'd still have to newgrp to the cdrom group > > before I could do anything, right..? > > AFAIK cdrecord can be installed setuid (dpkg-reconfigure ...). Then add > yourself to the cdrom group. While this is not the best solution it's > still better than burning cdroms as root. I thought the whole point about setuid root was to make it possible for unprivileged users to seamlessly run programs that require superuser privileges without granting them the ability to su by giving away the root password. So that Joe User can log in to the system or change his password without outside intervention for instance. Functionally, I can't see any reason why burning cdroms should require superuser privileges .. and presumably nobody else does. Which means that the code -- which may be quite complex -- may not have been audited for possible vulnerabilities (or backdoors .. who knows ..) as thoroughly as say, /usr/bin/passwd or /bin/login .. Frankly, I don't understand why having made cdrecord setuid root as you advise would be more secure than su'ing to it. I would have thought the reverse since I now have yet another program that's setuid root lying around that could potentially be used for an exploit at any time .. possibly when I am not looking .. which strikes me as marginally less secure than running cdrecord as root. Because in all other respects .. it's exactly the same thing. In both cases cdrecord runs with superuser privileges. Or am I missing something? Also, what is "the best solution"? Thanks. cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
