_whoami function: not valid in this context: /root

[fsLeg]

Just tried to test the latest snapshot of Tomb. I can create tombs normally, but whenever I need to enter a password for a key I get this error:

_whoami:local:30: not valid in this context: /root
tomb [W] User aborted password dialog.
tomb [E] No valid password supplied.

Latest stable (1.5.3) doesn't seem to have this function and I don't have any problems manipulating the keys or opening tombs with it. But I can't do that with the latest snapshot.

My system is Slackware64 14.1.

[jaromil]

This might be an error when using as root? try removing local from line 194?

[jaromil]

Can you retry now? I cannot reproduce the bug, but I have committed some cleanups that might affect this. If its still occurring, can you paste the full output with the -D debug flag on? thanks.

[fsLeg]

This might be an error when using as root?

No, I invoke Tomb as a regular user.

Can you retry now? I cannot reproduce the bug, but I have committed some cleanups that might affect this.

Still the same error, except now it's at line 28, not 30.

try removing local from line 194?

When I do this, Tomb doesn't ask for a key's password at all, thinking I entered a blank password.

If its still occurring, can you paste the full output with the -D debug flag on?

$ LANG=C LC_ALL=C ./tomb -D forge ~/tmp/test.tomb.key -f
tomb [D] Identified caller: fsleg (500:1000)
tomb [D] Tomb command: forge /home/fsleg/tmp/test.tomb.key
tomb [D] Caller: uid[500], gid[1000], tty[/dev/pts/1].
tomb [D] Temporary directory: /tmp/zsh
tomb [D] Using sudo for root execution of './tomb -D forge /home/fsleg/tmp/test.tomb.key -f'.
tomb [D] Identified caller: fsleg (500:1000)
tomb [D] Updating HOME to match user's: /home/fsleg (was /root)
tomb [D] Tomb command: forge /home/fsleg/tmp/test.tomb.key
tomb [D] Caller: uid[500], gid[1000], tty[/dev/pts/1].
tomb [D] Temporary directory: /tmp/zsh
tomb  .  Commanded to forge key /home/fsleg/tmp/test.tomb.key
tomb  .  Commanded to forge key /home/fsleg/tmp/test.tomb.key with cipher algorithm AES256
tomb  .  This operation takes time, keep using this computer on other tasks,
tomb  .  once done you will be asked to choose a password for your tomb.
tomb  .  To make it faster you can move the mouse around.
tomb  .  If you are on a server, you can use an Entropy Generation Daemon.
tomb [D] Data dump using dd from /dev/random
256+0 records in
256+0 records out
256 bytes (256 B) copied, 24.9024 s, 0.0 kB/s
tomb (*) Choose the  password of your key: /home/fsleg/tmp/test.tomb.key
tomb  .  (You can also change it later using 'tomb passwd'.)
tomb [D] exec_as_user 'fsleg': ./tomb askpass Type the new password to secure your key
_whoami:local:28: not valid in this context: /root
tomb [E] User aborted.

[jaromil]

weird... can u change var "home" in "_home" in that function?

I cannot reproduce this prob on any machine yet.

[fsLeg]

can u change var "home" in "_home" in that function?

Didn't help.

[jaromil]

I hope you can figure it out. This might affect also other slackware users?

[fsLeg]

I'm at loss why this happens. I guess somehow variables that are set in _whoami leak into exec_as_user or something. Perhaps it's a zsh bug. My distro uses zsh-5.0.2.

Invoking ./tomb askpass "gimme your pass" as a regular user works fine, invoking it under sudo environment (sudo -i, thus defining $SUDO_USER variable) produces the error.

UPDATE: I upgraded zsh to the latest version, which is 5.0.7, but the problem persists...

[fsLeg]

This might affect also other slackware users?

Just tested it on my desktop, which runs much less heavily customized Slackware64-14.1. Same error.

[jaromil]

FTR the line reporting the error is

    local home=$(awk -F: "/$_USER/ { print \$6 }" /etc/passwd 2>/dev/null)

this is declaring a local var and assigning it the stdout of the awk command. Its rather trivial and such operations are done all over tomb. Can you run this command from CLI and from inside a script that you launch with sudo then? I recommend isolating it this way.

[fsLeg]

I tried that, and it works just fine. I tried the whole _whoami function line by line, it all works as expected, but when it's called inside Tomb, I get the error.

[jaromil]

OK the only way I could reproduce this error was by launching such a script with _USER being empty:

#!/bin/zsh -x
_USER="$1"
local home=$(awk -F: "/$_USER/ { print \$6 }" /etc/passwd)
print $home

is this also your case? (launch with or without arguments)

if this is the case then the problem is that in Tomb the _USER variable is undefined at that point. The solution would be to find out why (where is SUDO_USER defined?)

[jaromil]

I am suspicious about those [[ -n flags to check vars which we don't really use elsewhere. Can you try substituting the block at line 175 with this and see how it goes?

    # Set username from UID or environment
    _USER=$SUDO_USER
    [[ "$_USER" = "" ]] && { _USER=$USERNAME }
    [[ "$_USER" = "" ]] && { _USER=$(id -u)  }
    [[ "$_USER" = "" ]] && {
        _failure "Failing to identify the user who is calling us" }

[fsLeg]

is this also your case?

Probably. It's hard to tell.

where is SUDO_USER defined?

SUDO_USER is defined by sudo binary. This is how the script can drop privileges from root back to the current user.

I am suspicious about those [[ -n flags

They seem to make it so _USER variable always gets defined. I don't know what possibly can make it undefined.

Can you try substituting the block at line 175 with this and see how it goes?

Same error.

[fsLeg]

I tried adding echo "The _USER variable is: $_USER" right before that awk line. The results when I try to forge the key:

$ ./tomb forge -k ~/tmp/test.tomb.key -f
The _USER variable is: fsleg
Password:
The _USER variable is: fsleg
tomb  .  Commanded to forge key /home/fsleg/tmp/test.tomb.key
...
tomb (*) Choose the  password of your key: /home/fsleg/tmp/test.tomb.key
tomb  .  (You can also change it later using 'tomb passwd'.)
_whoami:local:29: not valid in this context: /root
tomb [E] User aborted.

At the gen_key step the whole added line is omitted. I suppose zsh assesses the whole function before it actually starts to execute it.

[jaromil]

Maybe I spotted a weird scoping problem because of the typeset -g there.

Try to remove the declarations? (they are anyway declared at beginning)

    # Set global variables
    typeset -gi _GID _UID
    typeset -g  _TTY _USER

remove this block.

[fsLeg]

Try to remove the declarations

Alas, no luck.

[jaromil]

I'm asking friends around if I can get access to a slackware box...

[fsLeg]

This comment gave me an idea. I changed the hashbang string to #!/bin/zsh -x to get even more detailed output. Here's the result of the command ./tomb -D forge -k ~/tmp/test.tomb.key -f &> ~/tmp/tomb.log: https://gist.github.com/fsLeg/217a85b7fabf6bfb7bf6

[melon3r]

I just tried to forge a key with the current head and I get the exact same error. On Gentoo, so this is not Slackware specific.

[fsLeg]

I guess I found the culprit. awk string expects only one match, while on Slackware:

$ grep root /etc/passwd
root:x:0:0::/root:/bin/bash
operator:x:11:0:operator:/root:/bin/bash

So the local home variable has "/root\n/root" instead of expected "/root", that's why _whoami fails. You can see that around line 2390 of my copypasta above.

[melon3r]

Nice catch! This should fix it: local home=$(awk -F: "/^$_USER/ { print \$6 }" /etc/passwd 2>/dev/null) (note the ^ before $_USER)

[hellekin]

OMG, how I let that pass is mysterious. I think I have two other branches with the correct line :(

[jaromil]

This one took a while, but we are almost done now.

Hellekin could you update the French translation? https://poeditor.com/projects/view?id=19628

[hellekin]

I don't have an account on this service. Why don't we use the previous one? Or a FREE-AS-IN-FREEDOM one?

[jaromil]

Feel free to use one you consider FAIF or just send the updated translations via email, or commit them directly into the repo.

I'd rather not ridiscuss use of poeditor here, there was an issue already.

Please note poeditor is just handy, but is not an obligation.

[melon3r]

@hellekin That discussion makes more sense on #158.