backintime

backintime copied to clipboard

Could someone shed some light on what this error is about, I'm trying to run it as root.

net.launchpad.backintime.InvalidCmd: Parameter 'cmd' contains non-whitelisted cmd/parameter (/bin/nice)

Thanks!

I've found that this error only occurs when I try and configure it to backup automatically when the drive is plugged in. If I use a fixed interval or on boot instead, I don't get an error.

i have the exact same error on arch, how can i help to fix this ?

try disabling "nice" options in the options tab

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

Same problem here

Thanks for reporting the issue.

Please give detailed information's about

• operating system: name, version, plattform (amd64, arm, ...)
• BackInTime version
• How was BackInTime installed

If possible please give us the full debug output (use --debug option when starting BiT).

Tell us the steps to reproduce that error.

Thanks in advance.

My setup:

• Manjaro Linux 21.3.7, kernel version 5.15.60, running on Intel i7-6820HK
• BackInTime version 1.3.2 installed from official Manjaro repository

Steps to reproduce:

• Start BackInTime
• Open Settings
• Change schedule to after disk connection (udev)
• Click OK
• Error message appears

Log (using --debug option): https://pastebin.com/mErzUr0R

Edit to add: problem does not occur with any of the other scheduling options selected.

Thanks for the information's. This is related to D-Bus which I'm not experienced with.

https://github.com/bit-team/backintime/blob/29e874f5080f7cf85c8297ea807cb8070a427c10/common/tools.py#L1733

I think the problem is here https://github.com/bit-team/backintime/blob/29e874f5080f7cf85c8297ea807cb8070a427c10/qt/serviceHelper.py#L104

If I understand it correctly, only nice and /usr/bin/nice are accepted (whitelisted) as outputs of which, but in my case it's /usr/sbin/nice

If I understand it correctly, only nice and /usr/bin/nice are accepted (whitelisted) as outputs of which, but in my case it's /usr/sbin/nice

Makes sense. sbin is for super-user only. Maybe Manjaro allow nice for root only?

I ask myself if we need nice at this point?

And I also ask if Manjaro offers a way to use nice in our case?

From @brummer-simon

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

Why does backintime appear in /usr/sbin? It definitely should not. How did you install it?

@wgranicki What does whereis backintime say on your system? Looking back into your debug output... DEBUG: [common/backintime.py:670 getConfig] config file: /root/.config/backintime/config Because of the location of that config file I assume you run BiT as root?

I don't think it's a Manjaro problem, because there's also /usr/bin/nice present. But I'm running BIT as root, because I want to backup the whole system, and not just the parts accessible to my user.

Why does backintime appear in /usr/sbin? It definitely should not. How did you install it?

It appears both in /usr/bin and /usr/sbin, because the latter is just a symlink to the former. As I said before, I installed it from the official Manjaro repository via pacman

Also, I tried disabling using nice in the Advanced settings tab, but then it complains similarly about ionice. Disabling ionice leads to /usr/sbin/backintime error as per @brummer-simon's comment

All of this seems quite strange, because neither which nor whereis report the /usr/sbin/ locations - regardless if run as root or not. But somehow BIT finds those and throws exceptions.

Thanks for your reporting and testing. I can reproduce the error on a virtual Manjaro 21.3.7 installation.

It's a total mystery to me why the system tries to use /usr/sbin/nice, especially since /usr/sbin is just a symlink:

[manjaro@manjaro ~]$ ls -ld /usr/sbin
lrwxrwxrwx 1 root root 3  9. Jun 09:53 /usr/sbin -> bin

As far as I can see, this is different on Debian and Ubuntu, so we are dealing with some sort of Manjaro specialty here.

A dirty workaround would be to include /usr/sbin/nice in the whitelist, but @brummer-simon has indicated that this might not even eliminate all problems:

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

Also, I see the same confusing behavior as reported by @wgranicki:

All of this seems quite strange, because neither which nor whereis report the /usr/sbin/ locations - regardless if run as root or not. But somehow BIT finds those and throws exceptions.

So, the prize question is: Why does backintime, on Manjaro, try to use binaries from /usr/sbin (such as /usr/sbin/nice) when run as root?

My Debian doesn't have a /usr/sbin/nice.

Maybe Manjor whereis always sort the entries descending by there user rights.

In the reported case BiT run as root so the sbin folder is used instead.

Maybe Manjor whereis always sort the entries descending by there user rights.

In the reported case BiT run as root so the sbin folder is used instead.

It's not quite so simple, because on the terminal, whereis nice does not point to a /usr/sbin location (and neither do other tools):

[manjaro ~]# whereis nice
nice: /usr/bin/nice /usr/include/nice [...]
[manjaro ~]# which nice
/usr/bin/nice
[manjaro ~]# type nice
nice is /usr/bin/nice

My best guess is that the reason is hidden in some place where Manjaro and Python meet (like default paths in the sys or os modules, or something).

Did you tried to run whereis nice via sudo and as root (sudo su)?

I see this code and would say bit does nothing less then just call whereis nice but as root.

My best guess is that the reason is hidden in some place where Manjaro and Python meet (like default paths in the sys or os modules, or something).

I don't think so because bit don't use python stuff to find nice but just call whereis on a shell.

I have tested it in all three variants: as regular user, with sudo and as root. Every time the results are the same, and they never include the symlinked sbin, only /usr/bin/nice

Good reason for me to create a Manjaro machine...

You're both right, and I've gotten one step closer to the root (hah!) of the problem.

1. The problem does not occur when running sudo backintime-qt. Also, sudo which nice returns /usr/bin/nice, as expected.
2. The problem does not occur from a root shell called by sudo su (or just su). Also, which nice called from this root shell returns /usr/bin/nice, as expected.
3. But, the problem does occur when running Manjaro's "Back In Time (root)" application from the Desktop Environment's menus.

So, I investigated the last case. The menu application calls /usr/bin/backintime-qt_polkit, and this is a script which ultimately calls: pkexec [...] /usr/bin/backintime-qt

So when backintime is run as root from the application menu, it's not sudo that's involved with the elevated privileges, but PolicyKit's pkexec. And here's the smoking gun:

$ pkexec which nice
/usr/sbin/nice

So there, it's PolicyKit deciding that /usr/sbin should be the prefix for whatever's happening, and thus colliding with backintime's whitelist containing /usr/bin/nice only.

For the moment, I don't have a good idea what to do about that ;)

Just in case, I also tested running Popen(['which', 'nice'], stdout = PIPE).communicate()[0].strip().decode() in Python console (again as regular user, with sudo and as root) and the results are the same as before.

I confirm, that it's definitely pkexec's fault:

$ pkexec which nice
/usr/sbin/nice

From a quick test, it looks like in Ubuntu (and probably Debian), pkexec works similarly – but /usr/bin and /usr/sbin are actually separate folders.

Therefore, pkexec nice [program] only suggests executables in /usr/sbin if they really exist there.

$ pkexec which nice
/usr/bin/nice
$ pkexec which fsck
/usr/sbin/fsck

This makes me think that it's a bad design decision by Manjaro to symlink /usr/sbin to /usr/bin, but there's nothing backintime can do about that.

Maybe we can question why BIT needs nice and if it can't use /usr/bin/nice by default on all systems not matter if run as root or user. I don't understand the background here.

If not this should be reported to Manjaro. Maybe they have a better idea.

This makes me think that it's a bad design decision by Manjaro to symlink /usr/sbin to /usr/bin

I don't think that's a bad decision in itself... But combined with this ↓ it creates the mess we see

$ pkexec env | grep PATH
PATH=/usr/sbin:/usr/bin:/sbin:/bin:/root/bin

I don't agree with your statement, that

there's nothing backintime can do about that.

I see at least two options here:

• whitelist /usr/sbin/nice (probably also /bin/nice and /sbin/nice), not just /usr/bin/nice
• modify the script to just check if nice is available on the system instead of verifying (whitelisting) the full path, or parse the output of which for *bin/nice

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

Same problem here

Still a problem. After disabling nice and ionice appears the "non-whitelisted command/parameter" /usr/sbin/backintime dialog.

backintime-qt 1.3.3-1
backintime 1.3.3-1 Both installed from Manjaro "Community" repo (can't remember which package manager).

Operating System: Manjaro Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12-1-MANJARO (64-bit) Graphics Platform: X11

Please open a ticket at Manjaro and/or Arch about it and leave us a link here. Because it seems to be Manjaro specific I would like to hear there expertise and opinion about it.

Manjaro post.

@buhtz Manjaro packager here. Please define how this issue is specific to Arch / Manjaro. I skimmed through this issue since it was brought to my attention on the Manjaro forum, but it's very hard to follow.

If there's something to be done packaging-wise, I'm happy to do it.

The Manjaro backintime split package can be found on our GitLab.

By the way, I follow Fedora more than I do the AUR package.

Please define how this issue is specific to Arch / Manjaro.

Thanks for coming in :) Here's what's happening:

1. Manjaro has /usr/sbin symlinked to /usr/bin.
2. Running the "BackInTime (root)" application uses pkexec to elevate permissions.
3. Under pkexec, paths are configured such that which foo returns /usr/sbin/foo if it exists. Else, it returns /usr/bin/foo.
4. backintime looks for the nice executable by calling which nice, but it's configured to only ever allow /usr/bin/nice as the answer. Else, the abovementioned Exception is thrown.

Now, if you run "BackInTime (root)" on Manjaro, the following things happen: 2 leads to 3, which leads to which nice returning /usr/sbin/nice because of 1, which leads to 4.

My best guess as to why this happened is that:

• /usr/sbin/nice is not, and has never been, a thing, which is why backintime has always gotten away with only accepting /usr/bin/nice as the return value of which nice.
• Manjaro and Arch (uniquely?) chose to symlink /usr/sbin to /usr/bin.
• Because of the way pkexec handles paths, this problems occurs only:
  • on Manjaro and Arch,
  • and only for "BackInTime (root)".

In summary, it's not a Manjaro issue then. As it seems you are aware, Manjaro inherits almost everything from Arch.

Why would the same thing not happen on Fedora, for example? Arch-based distros are not the only ones that don't use /usr/sbin/.

Well, if nothing changes on the distro and packaging side of things, our best way to keep "BackInTime (root)" working on Arch and Manjaro is probably to do one of the things that @wgranicki suggested:

I see at least two options here: * whitelist /usr/sbin/nice (probably also /bin/nice and /sbin/nice), not just /usr/bin/nice * modify the script to just check if nice is available on the system instead of verifying (whitelisting) the full path, or parse the output of which for *bin/nice

Any opinions on the best way forward?