Thanks all around!
Rob: indeed, the system was compromised, sort of. The malware: some kind
of "endpoint security" thing that the Company IT folks installed, on top
of selinux, apparently because of a STIG. It's so seamless, it doesn't
even tell you what's going on, just tells you operation not permitted. I
wonder how it works ... must require some kind of kernel patch or
module. Killed the daemon and problem solved. Of course now I have to
wonder what in particular it doesn't like about all the files it selects
for this special treatment. But at least now I can backup all my files,
even the ones I'm not allowed to view.
Which I need to do because they "must" upgrade me to a newer RHEL and
apparently it requires everything to be wiped, even /home. There has got
to be a better Linux distro out there. If only I could remember its name ...
Thanks again. I'm buying the first round at the next UMGLUG. That day
will come!
regards
Judah
On 6/28/24 15:05, Rob Sherwood wrote:
I wouldn't ignore the possibility of a compromise... might be worth
booting off a known safe USB disk in rescue mode and seeing if the
problem persists even in that environment.
Best of luck,
- Rob
.
On Fri, Jun 28, 2024 at 11:21 AM J. Milgram <milg...@cgpp.com> wrote:
On Jun 28, 2024 at 14:19, J. Milgram <milg...@cgpp.com> wrote:
Peter, Moshe,
Thanks. These are good ideas. I might mention I'm running a RAID1
array so I presume an asymmetrical hd problem would trigger major
warnings. It never happened to me before so I don't actually
know what happens, or how to recover.
But I guess the raid array could be fine, and
reliably/redundantly supporting a broken filesystem...
Am running a search now to find all affected files, to see if
there's a pattern. Will check the logs too... Should have been
the first thing I thought of :) Like the dd idea too. Thanks again.
More to follow.
Judah
On Jun 28, 2024 at 10:41, peter teuben <teu...@umd.edu> wrote:
inclined to think the disk has I/O issues, though you mentioned
repair claims there's nothing needed.
Any suspicious logs in /var/log
or try dd if=/dev/yourdisk of=/devnull
to see if that triggers I/O errors in the logs
On 6/28/24 10:38, J. Milgram wrote:
Greetings,
Hope everyone's summer is going well.
Weird problem here on an RHEL 7 box. Have a number of files
under /home that the os will not let me read. So tools like cp,
md5sum, lsattr and such, and applications, all tell me
"operation not permitted" whether run as user or as root. That
said I can stat them. Have checked ownership, permissions, file
acls, etc.
Haven't found a pattern to the affected files. One interesting
example is a directory of ~300 conference papers, all pdfs, all
from same conference, all with identical perms and ownership,
and exactly one of them has this problem. The rest I can read
as normal.
Running selinux but disabling that didn't change anything.
It's an XFS filesystem. Ran xfs_repair but no change.
I'm stumped! Any ideas?
Thanks as always...
Judah
You received this email because you are subscribed to the UM
Linux User's Group (UM-LINUX) mailing list. If you would like
to unsubscribe from this list, simply send an email to
lists...@listserv.umd.edu with the message signoff UM-LINUX in
the body.
You received this email because you are subscribed to the UM
Linux User's Group (UM-LINUX) mailing list. If you would like to
unsubscribe from this list, simply send an email to
lists...@listserv.umd.edu with the message signoff UM-LINUX in
the body.
You received this email because you are subscribed to the UM Linux
User's Group (UM-LINUX) mailing list. If you would like to
unsubscribe from this list, simply send an email to
lists...@listserv.umd.edu with the message signoff UM-LINUX in the
body.
--
=====
milg...@cgpp.com
301-257-7069
You received this email because you are subscribed to the UM Linux User's Group
(UM-LINUX) mailing list. If you would like to unsubscribe from this list,
simply send an email to lists...@listserv.umd.edu with the message signoff
UM-LINUX in the body.
