As part of pkg_preinst() in mythtv-0.19_p9163.ebuild the command: usermod -G ${MYTHTV_GROUPS} mythtv" is executed which resets the mythtv users supplementary groups. Removing any groups added by the system administrator. perhaps it should use gpasswd instead
Nope. No editting of the groups necessary. Suggest some legit groups that mythtv should have access to and I will add it to the ebuild.
My issue was simply, that the mythtv user running mythtv on my system need to access files not owned by the mythtv user nor belonging to the "video,audio" groups. So my wish was to have the ebuild only to ensure that the mythtv user is in the "required" groups, and not revoke any additional groups which may have been added to the mythtv user, after the initial installation. So how about remowing "usermod". enewuser() creates the user if it is missing, with the required groups. I dont see why this ebuild should change my setup, by resetting the mythtv users groups.
Give me an example and I'll consider it. Otherwise the current answer is no. Unfortunately there's too much screwing up of allowed configs and tons of reported bugs and tons of spamming of MythTV related lists with issues that have just simply been resolved by me locking down the ebuild more.
One example is the 'game' group. MythGame requires that the 'mythtv' user be in the game group. How about adding the following to the ebuild: MYTHTV_GROUPS="$( groups mythtv | sed 's/ /,/g' ),$MYTHTV_GROUPS" prior to: usermod -G ${MYTHTV_GROUPS} mythtv or simply: usermod -G $( groups mythtv | sed 's/ /,/g' ),${MYTHTV_GROUPS} mythtv That way the groups of 'mythtv' are not wiped out each time.
Sorry, just realised that the groups would grow each time the above line is run. So the above is not quite right, it would require stripping the any duplicates; a quick awk would probably do the job.
The following will remove the problem of duplicated entries. for i in $( groups mythtv ) $MYTHTV_GROUPS; do echo $i; done | sort | uniq | awk '{printf("%s,",$1)}' | sed 's/,$/\n/g' | grep ^ Not the cleanest bit of code, and could probably be done entirely in awk, but it works.
I think the problem is using -G without -a (from the man page) so the current groups get removed if they aren't in the list. -a I assume appends.
if USE dvd is set, "cdrom" group should be added. (Technically, mythdvd should add access to the cdrom group, but it seems reasonable that if mythtv is merged with +dvd, that it should have access to the device.)
I only have one user on my mythtv system and he/she is called mythtv. So I want mythtv in wheel. I don't think any ebuild should ever clobber anything in /etc/group
It's a security issue. Your MythTV user should NEVER be in wheel. There's tons of other system groups for other daemons on your system where the ebuilds and even the Makefiles for the daemons hard set what the groups are.
Perfect example... Would you ever login to your webserver as the user "apache"? No? Well you should treat the "mythtv" user the same way. I don't care what others are doing or what some Fedora guide says. It's wrong. Another example... Would you ever add the "apache" user on your webserver to the "wheel" group? No? Well "mythtv" is the same. If you have or would consider adding "apache" to the "wheel" group... go to your local Walmart, buy a tazer gun, and go taze yourself until the batteries die... or the urge to add users to the "wheel" group passes... which ever comes later.
*** Bug 139844 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Give me an example and I'll consider it. Otherwise the current answer is no. > Unfortunately there's too much screwing up of allowed configs and tons of > reported bugs and tons of spamming of MythTV related lists with issues that > have just simply been resolved by me locking down the ebuild more. > As someone mentioned, the "games" group is required for using games, the "cdrom" group is needed for access to the dvd drive, the "usb" group could be used for access to removable media for MythGallery. Every time I emerge a new version of mythtv, I can't play DVDs until I remember that I have to re-add mythtv to the cdrom group. I think the point is that the ebuild shouldn't break existing installations. I understand the desire for security but I don't think this ebuild is the place to enforce it. But to the guy that has mythtv in wheel--seriously???
I second Gary and Karl's requests to have mythtv added to the cdrom group. It has been driving me nuts not being able to play dvds after emerging a new version of mythtv.
> I think the point is that the ebuild shouldn't break existing installations. I third that. How one sets up their system is entirely up to them. I was under the impression that the point of Gentoo/Portage was to allow a user 'complete' control over their system and for them to tailor a system to their liking but by changing an existing installation/configuration it removes the element of control. The user should be the one in control not the packaging system. The possibility of what group(s) mythtv should be a member of are as endless as the different Gentoo installations; eg mythphone users may have a phone group, mythweather users may have a network access group (eg iptables level network access control), users may need a firewire group to access their DVD/TV adaptor, the list is endless. If one insists on clobbering the existing groups then please add a USE option to allow non-clobbering of groups. That way the user is in control, and if they need non-standard groups then all they do is specify a USE option. Please don't be like other distributions and assume the user is dumb and the packaging system knows best. Power should for the user and not for the system.
Can this bug be reopened? It looks like the issues raised in Comment #13 have not been addressed in the newest 0.19 ebuild or the 0.20 ebuild. Doug explained well why mythtv should not be in the wheel group (and I have since created a normal user that is in wheel), but I don't think he explained why the mythtv user can't be in the cdrom or games groups.
The 0.20 does -a for append. The issue is moot.
