The tmp file doesn’t exist after i clicked cancel
You must log in or register to comment.
I’d like to see the bunnies please.
🥹❤️
Fuck yeah
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
unisonrather than NFS? If that’s the case, there won’t be an entry for ~/Dropbox if youcat /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,~/Dropboxwould 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
~/Dropboxcan 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.
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.
