So i got a notification that this command was executed by the user www-data:
cp --dereference --preserve=all /etc/passwd /tmp/coolwsd.dZO2nCn5iU/systemplate/etc/passwd
and coolwsd is from collabora, so i’m a bit worried that something not quite right is happening. The vps is running the latest nextcloud updates, firewall etc etc.
Is there anyone who can shed some light on this?
Hello @Bouncing8620,
welcome to the community of Nextcloud 
You started a topic in support category. Unfortunately you ignored the template and a lot of information to help you is missing. Please edit your original post and add all required details like Nextcloud version, webserver type and version, os version, related log file content. Use the support template.
Definitely it looks strange and you should take a closer look. as Collabora Online (coolwsd) seems involved I recommend to reach out in Collabora forum to get more specific advice.
Regards,
wwe
Please switch paranoia level down. You have not been hacked!
The coolwsd works from within a sandboxed chroot environment and needs to copy and/or create some system files, such as
/etc/group
/etc/host.conf
/etc/hosts
/etc/ld.so.cache
/etc/ld-so-conf
/etc/localtime
/etc/nsswitch.conf
/etc/passwd
/etc/resolv.conf
/etc/timezone
(and more) into the system-template (systemplate) folder, where the chroot sandbox environment is located.
You are using the richdocumentscode - “Collabora Online - Built-in CODE Server” App. In that app, the whole thing is stored in a kind of container in the /tmp directory. Since this is an app installed by Nextcloud, it is run by the Nextcloud/Webserver user (www-data). Therefore, that is the user who copies this file.
So it’s a security feature, not an attack.
(Incidentally, a hacker can’t do much with the world-readable passwd file. There’s nothing sensitive stored in it.)
h.t.h.
Much and good luck,
ernolf
Perhaps it should be added that many years ago, passwords were stored in encrypted form in /etc/passwd. This was a security risk, as all users needed access to /etc/passwd to determine user information, for example. Nowadays, passwords are stored in /etc/shadow if they are stored locally. The user www-data can not access /etc/shadow. However, the name /etc/passwd has been retained even though it does not really fit.
Well, paranoia wouldn’t be the right term. i checked my firewall, auth logs, etc etc. but i did was a bit worried 
Thanks everyone for the explaination, this makes much more sense now! From the collabora forum i gathered this is normal behavior. It’s also in their documentation, but someone explained it much more clear then the documentation, same as the good and friendly replies here! Thanks everyone i am feeling much more better now!
for reference direct link to the thread:
Yes, but that are realy many, MANY years ago!
The shadow password file library which was ported to linux in 1992 is from 1988.
Linus Torvalds begun its first developments on the linux kernel in 1991
It was in 1992 that the first free Linux distributions were created. Debian was begun in August 1993. So you could say that Linux has always used shadow passwords from the very beginning. At least long before Nextcloud even existed: OwnCloud dates back to 2010 and Neytcloud to 2016, so the Shadow Password Suite had already been around for 28 years, as the first Nextcloud version after the fork (9.0.54) was released at the end of September 2016. That was nine years ago!
I think so. Many firewalls have something like a paranoia level that you can set. So, that’s exactly the right technical term in this case 
ernolf
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.