Hide Forgot
Description of problem: after RPM up(2)date to mailman-2.1.5-8.fc2 discovered altered /etc/gshadow (I've restored to the proper file): [root@localhost etc]# diff gshadow.crap_from_RPM_update_050210 gshadow 48c48 < mailman:x::,n,,,,,,n,,,n,,,,an,,x,,,, --- > mailman:x:: where [root@localhost etc]# di gshadow.crap_from_RPM_update_050210 ---------- 1 root root 755 Feb 10 03:20 gshadow.crap_from_RPM_update_050210 [root@localhost etc]# where the up2date ran at 03:20 on Feb 10. It appear this could be an exploit of some kind to me. I suppose it could just be sloppiness on your part and silliness on mine, but I thought it better to let you know and look silly if it is. Version-Release number of selected component (if applicable): mailman-2.1.5-8.fc2 How reproducible: If it is from the RPM (I can check which mirror it came from if you need me to, and you tell me where to look) you should be able to reproduce it...I don't care to. I grabbed the RPM from the duke site and popped it open and can't find anything to explain the gshadow alteration right off the bat (passwd and group were also touched, but not altered), but I'm not particularly clever (there's an awful lot of python code there, megs & megs). Steps to Reproduce: 1. d/l rpm & install with up2date 2. 3. Actual results: Expected results: Additional info:
I can't explain this either. I've never seen it before. There is nothing in Mailman that alters the user and group information, this is all in the %pre script of the spec file. I'm attaching the relevant lines that invoke the commands to add or modify the user/group for mailman. I regularly install mailman rpm's on our different releases and I've never seen this before. I'm cc'ing our resident shadow expert, Nalin, to see if he can identify anything. If Nalin doesn't see anything suspicious maybe we'll just chalk this up as bizarre unless it shows up again.
Created attachment 111113 [details] contents of %pre that creates or alters mailman user/group
I had exactly the same experience after using 'yum update' to install about 2 weeks of updates (including mailman-2.1.5-8.fc2).
Scott, with respect to comment #3, was the mailman entry in gshadow identically altered in your case as was originally reported? In other words did it end up looking like this: mailman:x::,n,,,,,,n,,,n,,,,an,,x,,,,
Yes, which I just verified with 'fgrep -x /etc/gshadow~'. In fact, I found this bugzilla entry by searching for ",n,,,,,,n,,,n,,,,an,,x,,,," in google!
After talking with Nalin the conclusion seems to be this must be an issue with shadow-utils and not mailman. So I'm changing the component to shadow-utils.
The problem is maxmem.patch in shadow-utils. Use shadow-utils >= 2:4.0.3-59.
But Peter, shouldn't this upgrade (to shadow-utils >= 2:4.0.3-59) be in an Up2Date package for FC2? I think I have (and had) run all the stuff Yum had told me about (told my computer about, really). I look and have: - [root@localhost src]# rpm -qa | grep shadow-utils - shadow-utils-4.0.3-55 - [root@localhost src]# Just thought you guys were gonna save me from having to know/figure this stuff out. Shouldn't there be a "requires" in the mailman RPM or something? Thanks for running the obscure "what the hell?..." down. Cheers, (lazy, apparently...) Bruce -------------------------------------------------------------------- (In reply to comment #7) > The problem is maxmem.patch in shadow-utils. > Use shadow-utils >= 2:4.0.3-59.
Created attachment 111976 [details] the latest shadow-utils from devel
I want to echo Comment #8: I have the same version of shadow-utils, and I frequently run "yum update".