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
[root@localhost etc]# di gshadow.crap_from_RPM_update_050210
---------- 1 root root 755 Feb 10 03:20
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):
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
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
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:
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
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
- [root@localhost src]# rpm -qa | grep shadow-utils
- [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
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".