The tmp file doesn't exist after i clicked cancel
I'd like to see the bunnies please.
this post was submitted on 24 Feb 2025
27 points (100.0% liked)
linux4noobs
1653 readers
13 users here now
linux4noobs
Noob Friendly, Expert Enabling
Whether you're a seasoned pro or the noobiest of noobs, you've found the right place for Linux support and information. With a dedication to supporting free and open source software, this community aims to ensure Linux fits your needs and works for you. From troubleshooting to tutorials, practical tips, news and more, all aspects of Linux are warmly welcomed. Join a community of like-minded enthusiasts and professionals driving Linux's ongoing evolution.
Seeking Support?
- Mention your Linux distro and relevant system details.
- Describe what you've tried so far.
- Share your solution even if you found it yourself.
- Do not delete your post. This allows other people to see possible solutions if they have a similar problem.
- Properly format any scripts, code, logs, or error messages.
- Be mindful to omit any sensitive information such as usernames, passwords, IP addresses, etc.
Community Rules
- Keep discussions respectful and amiable. This community is a space where individuals may freely inquire, exchange thoughts, express viewpoints, and extend help without encountering belittlement. We were all a noob at one point. Differing opinions and ideas is a normal part of discourse, but it must remain civil. Offenders will be warned and/or removed.
- Posts must be Linux oriented
- Spam or affiliate links will not be tolerated.
founded 2 years ago
MODERATORS
I looked at the file's content in another virtual console instead of pressing cancel. It recursively changes the Dropbox folder and contents to be owned by me and allow read+write+search by me.
Some googling suggests this is what Dropbox does when it doesn't like the owner or permissions of any files in the Dropbox folder. It is very weird though. I assume you have dropbox installed? It is syncing correctly? Running find /home/dullbananas/Dropbox/ ! -user 'dullbananas' will list any files in that folder that aren't owned by you.
Assuming your userid is 1000 (likely but not guaranteed), running the script should be harmless and stop the password prompt from appearing until there is another file permission issue. Check your user id with id -u 'dullbananas'.
One issue that Unix filesystems have with network filesystems is mapping userids (the "1000" there) across systems. Internally, Unix filesystems work with userids, but userids are not necessarily the same on one system as another (e.g. "tal@system1" might have userid 1000, and "tal@system2" might have userid 1002...or might not even exist on system2, for that matter.). So normally, a network filesystem needs to provide some kind of sane mapping.
This could be used to fix that.
The problem is that you'd think that if this is Dropbox -- which controls the filesystem and can decide what userid to expose -- they'd just handle this mapping at the filesystem level, not drop this kludge in on top.
Hmm.
thinks
Does Dropbox -- which I don't use -- maybe just provide file synchronization for some directly, not expose an actual filesystem via FUSE or something? Work like unison rather than NFS? If that's the case, there won't be an entry for ~/Dropbox if you cat /proc/mounts. Because that'd make sense if that's what it does and doesn't try to handle handle multiple user file permissions. In that case, ~/Dropbox would live on your local filesystem, and the Dropbox software would just run a program to periodically synchronize it with the servers.
In that case, Dropbox couldn't stop you or other software from creating files with whatever IDs you want, since it's not providing the filesystem, but it potentially wouldn't be able to make useful use of different permissions on. So instead of letting you set up a permissions structure that it cannot handle -- which you'd only discover when you synched it to another system, and permissions were broken there -- they could just slam the whole thing back to a canonical representation with a flat set of permissions.
EDIT: The Arch documentation makes it sound like this is indeed how Dropbox works -- that the client software just synchronizes files in a directory on the local filesystem, since apparently ~/Dropbox can be btrfs. If that weren't the case, there'd be a Dropbox filesystem type (and apparently there are Dropbox clients that can do that, but it's not what the official Dropbox client does; it just synchronizes to a local filesystem). Further, it does say that this root-permission-request-at-login is part of Dropbox:
https://wiki.archlinux.org/title/Dropbox
Dropbox asks for root on startup
This might be because it tries to fix permissions it does not accept. It can happen when you use btrfs on a partition that is used by Arch and Windows and forget to configure the Windows driver to use proper UID and GID. Check if that is the case:
find ~/Dropbox -user nobodyFix permissions and configure your driver properly. The asking for root modal should disappear automatically.
Note that this can appear if permissions on any file inside the Dropbox folder are incorrect, not only the Dropbox folder itself.
EDIT2: So, in short, getting at what you're probably concerned about, OP, your system probably isn't compromised, and this is probably the Dropbox software.
~~Confirm that you looked in "/bin/sh/tmp/" and not "/bin/sh /tmp" (notice the single space ' ' after the 'h').~~
Ignore my previous comment, I was incorrect. Apologies. I had thought it was malware trying to look like something else, and that the who thing quoted was the single command, and not a command and an argument/parameter.
/bin/sh is the shell binary. The other part of that string is the argument being passed to the shell. The whole thing looks sus.
I looked in /tmp
Reread what I wrote. There may be two subdirectories named '../tmp/' on your machine.
Edit: For anyone else, how do I type just two periods? When I do, it displays as an ellipsis, three periods.
Surely the space is part of the command. It's running sh with the file in /tmp as the parameter (run this file).
You're right. I assumed the whole thing is a single command, and not a command with an argument/parameter. My bad.
Didn't realize 'sh' was a shortcut to bash in and of itself. Thought you had to mark a file as an executable, like ".sh" files.
~This~ ~comment~ ~is~ ~licensed~ ~under~ ~CC~ ~BY-NC-SA~ ~4.0~
Escape one of them \.. => ..
Thank you!
That whole thing looks sus. Maybe you can copy the file by switching to another tty session when it asks for elevated permissions.
That whole thing looks very sketchy. Don't execute the arbitrary shell scripts as superuser.
I don't have a Fedora box to check for sure, but have a look in /var/log/secure, it might have details of the request and what program called it.