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:
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 nobody
Fix 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.
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
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.