[ERROR ] [Errno 13] Permission denied: '.'

[rjc]

Expected Behavior

$ cd $HOME && sudo salt-key -L

run in user's $HOME directory, which resides on NFS and has strict access permissions (0700) should still display the list of keys.

Actual Behavior

The above command run in user's home directory with very strict access permissions and which residing on NFS, causes the error below:

$ cd $HOME && sudo salt-key -L                                               
[ERROR   ] [Errno 13] Permission denied: '.'
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/salt/utils/parsers.py", line 167, in parse_args
    mixin_after_parsed_func(self)
  File "/usr/lib/python2.7/dist-packages/salt/utils/parsers.py", line 2000, in __create_keys_dir
    os.makedirs(self.config['gen_keys_dir'])
  File "/usr/lib/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '.'
Usage: salt-key [options]

salt-key: error: Error while processing <bound method SaltKey.__create_keys_dir of <salt.cli.key.SaltKey object at 0x7fed8155f3d0>>: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/salt/utils/parsers.py", line 167, in parse_args
    mixin_after_parsed_func(self)
  File "/usr/lib/python2.7/dist-packages/salt/utils/parsers.py", line 2000, in __create_keys_dir
    os.makedirs(self.config['gen_keys_dir'])
  File "/usr/lib/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '.'

Steps to Reproduce Issue

1. Set up an NFS server with 0700 permissions on user's $HOME directories.
2. On a client machine, which is not the NFS root, run cd $HOME && sudo salt-key -L - user obviously has local admin rights via sudo.
3. Get the above error message.
4. cd / && sudo salt-key -L works as expected and obviously doesn't display the message as there are no NFS access constraints on local /, which is then the $PWD.

Versions Report

* Provided by running salt --versions-report*

 salt --versions-report
                  Salt: 2015.5.3
                Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
                Jinja2: 2.7.2
              M2Crypto: 0.21.1
        msgpack-python: 0.3.0
          msgpack-pure: Not Installed
              pycrypto: 2.6.1
               libnacl: Not Installed
                PyYAML: 3.10
                 ioflo: Not Installed
                 PyZMQ: 14.0.1
                  RAET: Not Installed
                   ZMQ: 4.0.4
                  Mako: Not Installed
               Tornado: Not Installed
 Debian source package: 2015.5.3+ds-1trusty1

Relevant Logs, Configs, or States

** If not already provided above, please post any additional
information that can help us reproduce your issue such as
commands run with -l debug. Be sure to remove any
sensitive information. **

[jfindlay]

@rjc, thanks for reporting. Is it possible for you to reproduce this with the latest stable release of salt? It can be obtained from the saltstack repo: https://repo.saltstack.com/#ubuntu.

[rjc]

Yep, the same thing :^)

[rfparedes]

This is not a bug. This is expected behavior with sudo on an nfs mount exported without root privileges. If the nfs share is exported with root_squash (which it most likely is based on the behavior) then the uid 0 of the root user on the client machine is mapped to an unprivileged user. Therefore root doesn't have permission. Since it is a home directory of a user, then no one but the owner is going to be able to access the home directory at least from that client machine.

Specifically, when you run salt-key -L, it looks for a file called Saltfile in your current working directory and uses the cwd for the keys directory. Since root cannot access Saltfile or the directory, you get the error permission denied.

The fix on the salt side is to specify the gen-key-dir outside of this privileged NFS mount:
sudo salt-key -L --gen-keys-dir=/tmp

This will solve your issue.

The only fixes I see on the infrastructure side are either to export the nfs mount with no_root_squash (umount home directory and mount again after the change) or make sure the current working directory is not a NFS share with no root permissions.

[rjc]

Hi Rich,

Thanks for taking the time to reply.

In terms of salt-key failing altogether, no - this behaviour is not expected at all.

I'm well aware how NFS in general, and root_squash in particular, works, BTW :^)

This issue is strictly related to sudo - root user will experience exactly the same issue.

There are plethora of programs which complain about not being able to read from, or cd to, my $HOME directory but most of them spit out a meaningful error message and carry on working just fine. APT is just one such example:

$ sudo apt-get -qq update
E: Unable to change to $HOME - chdir (13: Permission denied)

or:

$ sudo apt-get install xyz
[...]
dpkg: warning: failed to open configuration file '$HOME/.dpkg.cfg' for reading: Permission denied
[...]

So no, changing NFS permissions is not the way to fix this and simply out of the question here - having restrictive NFS permissions is not something unusual :^)

Also, the option you speak of simply doesn't make sense in its current state:

man 1 salt-key
[...]
Key Generation Options
       --gen-keys=GEN_KEYS
              Set a name to generate a keypair for use with salt

       --gen-keys-dir=GEN_KEYS_DIR
              Set the directory to save the generated keypair.  Only works with 'gen_keys_dir' option; default is the current directory.
[...]

as salt-key -L doesn't generate any keys - it should either be something like WRKDIR and/or the description changed altogether.

As it stands, the bug is still there - salt-key should carry on working when $PWD is nether writeable, nor readable by root - it's an entirely different matter if root (or any other user) needs to and/or is expected to manipulate data in a particular directory.

Best regards,

Raf

[rjc]

Has there been any movement regarding this issue? ... it's been two years ;^)

[rjc]

Hi there,

Has there been any movement on this?

Cheers,

Raf

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[rjc]

It would be great if, rather than marking it as stale, this eventually got fixed! :^)

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[sagetherage]

The Core team won't be able to get to this in Aluminium, moving it back into planning for another release.

[whytewolf]

Closing this due to age, the old version of Salt and Python 2.
Can you retest this with the latest release of Salt and if still an issue, please open a new issue, which will have metrics in tracking issues.

[rjc]

Closing this due to age, the old version of Salt and Python 2. Can you retest this with the latest release of Salt and if still an issue, please open a new issue, which will have metrics in tracking issues.

Why!? This has absoletely nothing to do with Python version - the error is exactly the same:

$ cd $HOME && sudo salt-key -L
Usage: salt-key [options]

salt-key: error: Error while processing <function SaltKeyOptionParser.__create_keys_dir at 0x7f5a940385e0>: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line 212, in parse_args
    mixin_after_parsed_func(self)
  File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line 2777, in __create_keys_dir
    os.makedirs(self.config["gen_keys_dir"])
  File "/usr/lib/python3.8/os.py", line 223, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '.'