New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"storage/oauth-private.key" does not exist or is not readable. #418

Closed
siarheipashkevich opened this Issue Jul 3, 2017 · 56 comments

Comments

Projects
None yet
@siarheipashkevich
Copy link

siarheipashkevich commented Jul 3, 2017

Hi, today I updated composer and I got this error:
Operation failed: Operation not permitted

I have resolved this probem by running the following commands:
chmod 600 storage/oauth-private.key
chmod 600 storage/oauth-public.key

But then I got the following error:
"storage/oauth-private.key" does not exist or is not readable

Thanks for help

@siarheipashkevich siarheipashkevich changed the title ".../storage/oauth-private.key" does not exist or is not readable. "storage/oauth-private.key" does not exist or is not readable. Jul 3, 2017

@alexbilbie

This comment has been minimized.

Copy link
Contributor

alexbilbie commented Jul 4, 2017

@siarheipashkevich you need to ensure that the PHP process owns the private and public keys

@siarheipashkevich

This comment has been minimized.

Copy link

siarheipashkevich commented Jul 4, 2017

@alexbilbie could you please help me how can I check it?

@SmileYuhao

This comment has been minimized.

Copy link

SmileYuhao commented Jul 4, 2017

I think you didn't correctly install passport.

Please run this command:

php artisan passport:install
@siarheipashkevich

This comment has been minimized.

Copy link

siarheipashkevich commented Jul 4, 2017

@SmileYuhao I ran this command and I have installed keys.

@siarheipashkevich

This comment has been minimized.

Copy link

siarheipashkevich commented Jul 4, 2017

@alexbilbie I updated composer packages in the Homestead machine and I am not getting any errors, but in my local machine I get this error. I'm afraid that it will break my prod.

@bassco

This comment has been minimized.

Copy link

bassco commented Jul 4, 2017

The file permission changes introduced in 2.0.11 have been disastrous for us too. We host our laravel containers and publish the shared oauth keys via secret files using volume mounts in a kubernetes cluster.

The website runs under user www-data, but the secret files are mounted and owned by root.

We are pegging our application at 2.0.10 as we are unable to change the ownership of the files.

@jspicee

This comment has been minimized.

Copy link

jspicee commented Jul 4, 2017

Same issue

@lomby

This comment has been minimized.

Copy link

lomby commented Jul 4, 2017

We are also experiencing this issue over the last couple of days. The only workaround for us was to set the owner of these two files to www-data manually when they have always been root previously.

@maurice-ellis

This comment has been minimized.

Copy link

maurice-ellis commented Jul 4, 2017

The version 5.1.4 of \League\OAuth2\Server has a change that needs to be update in Passport.

https://oauth2.thephpleague.com/v5-security-improvements/

@shailesh87

This comment has been minimized.

Copy link

shailesh87 commented Jul 5, 2017

I am also facing same issue after composer update.

@andrefigueira

This comment has been minimized.

Copy link

andrefigueira commented Jul 6, 2017

Same issue here after a composer update, running in docker container, which by default runs everything as root. As @alexbilbie just need to make sure the keys are owned by PHP and it solves the problem, so it's not so much that the package broke anything but we've had it configured incorrectly and didn't read release notes and update our applications accordingly.

Check the ownership of the files easily using `ls - e.g.

[root@air-queue-workers notifications]# ls -l storage/
-rw------- 1 1001 root     3292 Jul  6 10:27 oauth-private.key
-rw------- 1 1001 root      812 Jul  6 10:27 oauth-public.key

Then just correct with chown or whatever way you automate your project setup...

chown correctuser:correctgroup storage/oauth-*.key
@iget-esoares

This comment has been minimized.

Copy link

iget-esoares commented Jul 7, 2017

This issue is causing big problems here.

The file should be owned by www-data when accessing on web, and by myuser when accessing artisan tinker, because it try to run chmod, that can only be called by file owner (or root).

@Wolg

This comment has been minimized.

Copy link

Wolg commented Jul 7, 2017

Having the same issue with Envoyer deployment.
when deploying and performing php artisan optimize we need those files to belong deployment user (ec2-user on aws). But it will break entire application 'cause when accessing on web it should belong to web-server user (nginx).

@andrefigueira

This comment has been minimized.

Copy link

andrefigueira commented Jul 7, 2017

@iget-esoares from what I can see in the code, it only attempts to run the chmod when the permissions are incorrect, so you could circumvent by having the permissions set at a higher level, for example your provisioning tool or deployment tool.

@shailesh87

This comment has been minimized.

Copy link

shailesh87 commented Jul 10, 2017

In the centos linux the command chown apache:apache /storage -R work for me.

@libasoles

This comment has been minimized.

Copy link

libasoles commented Jul 10, 2017

Well, according to /vendor/league/oauth2-server/src/CryptKey.php both files must be chown to http server (nginx/apache/whatever) and permissions set to 0600. Like:

sudo chmod 0600 storage/oauth*
sudo chown http:http storage/oauth*

Personally I dislike this. it breaks our existing code and forces me to set the user (not only the group) to http server.

This is the problematic commit: thephpleague/oauth2-server@2f8de3d

@libasoles

This comment has been minimized.

Copy link

libasoles commented Jul 10, 2017

Things are being quite in phpleague repo:
thephpleague/oauth2-server#760

@alexbilbie

This comment has been minimized.

Copy link
Contributor

alexbilbie commented Jul 11, 2017

I have released 5.1.5 which replaces the hard errors with notices and deprecation warnings.

It is correct behaviour that the key should be owned by the server process to prevent possibility of token forgery by replacing the server’s public key or leakage of the key by an attacker or rogue other process.

@vdjkelly

This comment has been minimized.

Copy link

vdjkelly commented Jul 12, 2017

chmod(/var/www/sanidad/storage/oauth-public.key): Operation failed: Operation not permitted

help me

@ryankazokas

This comment has been minimized.

Copy link

ryankazokas commented Jul 13, 2017

@andrefigueira i changed ownership of the keys to www-data and the permissions to 0600 within the docker container and now I'm getting an error prior to that when it is trying to find if the file is readable? Has this been happening to anyone else? Even if i keep the perms at 0600 and change the user;group back to root:root there is the same issue. This is tag 5.1.5 that has the notice instead of exception.

(1/1) LogicExceptionKey path "file:///var/www/storage/oauth-private.key" does not exist or is not readable

in CryptKey.php (line 44)

@libasoles

This comment has been minimized.

Copy link

libasoles commented Jul 13, 2017

@ryankazokas it's not root:root, but server:server (meaning apache2:apache2, http:http, or whatever user you have in your server)

@ryankazokas

This comment has been minimized.

Copy link

ryankazokas commented Jul 13, 2017

@libasoles , you are correct, i was able to find the correct user/group combo for my apache2, but now I'm receiving:

(1/1) ErrorExceptionYou must set the encryption key going forward to improve the security of this library - see this page for more information https://oauth2.thephpleague.com/v5-security-improvements/

in AuthorizationServer.php (line 142)
at HandleExceptions->handleError(16384, 'You must set the encryption key going forward to improve the security of this library - see this page for more information https://oauth2.thephpleague.com/v5-security-improvements/', '/var/www/vendor/league/oauth2-server/src/AuthorizationServer.php', 142,array('grantType' => object(AuthCodeGrant), 'accessTokenTTL' => object(DateInterval)))

i confirmed that the permissions are 0600.

-rw-------  1 laradock laradock  812 Jul 13 03:15 oauth-private.key
-rw-------  1 laradock laradock 3292 Jul 13 03:15 oauth-public.key
@libasoles

This comment has been minimized.

Copy link

libasoles commented Jul 13, 2017

@ryankazokas Well, that's a basic step in Laravel. You must generate an APP_KEY and store it in your .env file. Use: artisan key:generate.

@ryankazokas

This comment has been minimized.

Copy link

ryankazokas commented Jul 13, 2017

@libasoles i've done this, and just to reassure myself i did it again and still receive the same error. The error seems to be unrelated(although i'm not positive, so i can hack away at it and if i need a new issue thread for that or need to come back, I will go that route. Thanks!

@namelivia

This comment has been minimized.

Copy link

namelivia commented Jul 13, 2017

@libasoles @ryankazokas The unset key that triggers the error is a property called encryptionKey belongin to the class League\OAuth2\Server\AuthorizationServer. This class has a setter method for that property but I've looked through the code and I don't see any call to that method, so it stays as null and the error is triggered.

@ryankazokas

This comment has been minimized.

Copy link

ryankazokas commented Jul 13, 2017

@namelivia yeah i saw why the exception was happening. Wasn't sure where or why it wasn't being set. What version are you using?

@indra1

This comment has been minimized.

Copy link

indra1 commented Jul 13, 2017

@Wolg just update your envoyer to run chmod at the end to return oauth keys to www-data. I just got this error and i'm still stuck with it

I did this and it worked:
@task('update_permissions')
chgrp -R www-data {{ $app_dir }};
chmod -R ug+rwx {{ $app_dir }};
chown -R www-data:www-data {{ $app_dir }} . '/storage/oauth-*.key';
@endtask

@ryankazokas

This comment has been minimized.

Copy link

ryankazokas commented Jul 13, 2017

@libasoles @namelivia
I was able to fix this by updating to the newest version(3.0) of laravel\passport
The constructors are different from v2 to v3. 6dc37eb

Should the composer file in 2.0.11 and below change the league outh dependency?
currently it is:
"league/oauth2-server": "~5.0",

@namelivia

This comment has been minimized.

Copy link

namelivia commented Jul 14, 2017

As @ryankazokas previously mentioned, seems that updating passport to 3.0 solved the issue.

@k1m0ch1

This comment has been minimized.

Copy link

k1m0ch1 commented Jul 14, 2017

every time I set to the right owner, passport will reset the owner, please fix this without upgrading to 3.0 :(
currently I set the cronjob to the server :(

@bbdangar

This comment has been minimized.

Copy link

bbdangar commented Jul 17, 2017

@namelivia mine is already on ^3.0, I mentioned above is in 3.0

@ryankazokas

This comment has been minimized.

Copy link

ryankazokas commented Jul 17, 2017

@bbdangar Are you sure you are providing the 600 permissions to the correct user. They should be sufficient enough to pass the is_readable method. The same thing happened to me since I am running laradock and docker the user:group combo i needed was laradock:laradock

@bbdangar

This comment has been minimized.

Copy link

bbdangar commented Jul 18, 2017

drwxrwxrwx 6 bbdangar bbdangar 4096 Jul 14 13:09 . drwxrwxr-x 13 bbdangar bbdangar 4096 Jun 1 17:20 .. drwxrwxrwx 6 bbdangar bbdangar 4096 Jun 16 18:24 app drwxrwxrwx 2 daemon daemon 81920 Jul 17 21:33 debugbar drwxrwxrwx 6 bbdangar bbdangar 4096 May 11 18:12 framework drwxrwxrwx 2 bbdangar bbdangar 4096 May 30 16:49 logs -rw-r--r-- 1 www-data www-data 3292 Jul 14 16:39 oauth-private.key -rw-r--r-- 1 www-data www-data 812 Jul 14 16:39 oauth-public.key
who is the correct user in this case? bbdangar?? I have tried to change ownership but didn't work. I got it working by modifying CryptKey.php

@etertime

This comment has been minimized.

Copy link

etertime commented Jul 19, 2017

@libasoles The HTTP server settings owner can solve the problem.,no problem, at least it can run

But the nginx server settings are ineffective, such as:

chmod 600 storage/oauth-p*
chown nginx:nginx storage/oauth-p*

The nginx here is the nginx server user, in the nginx.conf configuration

Result:

-rw------- 1 nginx nginx 3.2K Jul 19 15:03 oauth-private.key
-rw------- 1 nginx nginx  799 Jul 19 15:03 oauth-public.key

Key path "file:///var/www/NewDrugsSuperviseSystemApi/storage/oauth-private.key" does not exist or is not readable

@indra1 Have you tested the nginx server, please?
Who can solve this problem, someone upgraded to 3.0 (#435), or there are problems!

@libasoles

This comment has been minimized.

Copy link

libasoles commented Jul 19, 2017

@etertime I run nginx but inside docker. For me is http:http and it works. Are you using virtualization?

And yes, you'll have to upgrade to Passport 3. No problems.

@alexbilbie

This comment has been minimized.

Copy link
Contributor

alexbilbie commented Jul 19, 2017

Please upgrade to Passport 3.0.* to address these issues.

I've pushed a fix to the parent library so that there are no longer any hard errors being thrown if the key files doesn't have 600 permission.

I'm going to close this issue for now. If you're still having issues after upgrading to Passport 3.0.* please open a new ticket and I will try and help you.

@kmligue

This comment has been minimized.

Copy link

kmligue commented Aug 5, 2017

Thanks @libasoles. It fixes my issue. In second command, I changed "http:http" to "www-data:www-data".

@coreation

This comment has been minimized.

Copy link

coreation commented Aug 7, 2017

@alexbilbie what about L5.3 users? Passport 3.0.* requires Illuminate packages for 5.4... I'm running Passport 1.0 at the moment.

@jcc jcc referenced this issue Sep 2, 2017

Closed

关于权限问题 #69

@MrKriegler

This comment has been minimized.

Copy link

MrKriegler commented Sep 6, 2017

If you are having this issue on mac then

sudo chown _www:_www storage/oauth-*.key

Fixed my issue

@nadeemse

This comment has been minimized.

Copy link

nadeemse commented Sep 23, 2017

sudo chown www-data:www-data storage/oauth-*.key
Saved my hours of effort 👍

@adangbryen

This comment has been minimized.

Copy link

adangbryen commented Dec 1, 2017

If the file is not exist use the following cmd

php artisan passport:keys
@Braunson

This comment has been minimized.

Copy link

Braunson commented Dec 19, 2017

I had this issue with Jenkins, turned out I just needed to add php artisan passport:keys into my deploy pipeline.

@hemorej

This comment has been minimized.

Copy link

hemorej commented Jan 15, 2018

I'm on Heroku, I've generated the keys with php artisan passport:keys and set the permission to 600 but Passport still complains about the keys

@MrKriegler

This comment has been minimized.

Copy link

MrKriegler commented Jan 15, 2018

@hemorej you must set the owner of the keys to your web server. On mac this helped me

sudo chown _www:_www storage/oauth-*.key

_www is the apache user find yours and change the owner

@hemorej

This comment has been minimized.

Copy link

hemorej commented Jan 15, 2018

@MrKriegler it's already set to the owner, with 600 as the permission

@hotrush

This comment has been minimized.

Copy link

hotrush commented Mar 13, 2018

I am using passport 5.0 with laravel 5.6. Of course i do not store this keys in vcs, and when i deploy the project first time i get this error at composer install stage.

composer install --no-dev --prefer-dist -o

Loading composer repositories with package information
Installing dependencies from lock file
...
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover

In CryptKey.php line 45:
                                                                               
  Key path "file:///home/.../public_html/storage/oauth-private.key" does not exist or is not readable                                                  
                                                                               

Script @php artisan package:discover handling the post-autoload-dump event returned with error code 1

Of course it does not exist, it does not generated yet!

@hshahdoost

This comment has been minimized.

Copy link

hshahdoost commented Jul 30, 2018

@hotrush I get the same error on Debian 8, with php7.2 and laravel 5.6

@Razorsheep

This comment has been minimized.

Copy link

Razorsheep commented Aug 1, 2018

@hotrush I'm getting this too, when I try to enable a custom grant from the AuthServiceProviders boot method. Is there a nice way to check whether the key has been created before I try to enable to grant?

@hotrush

This comment has been minimized.

Copy link

hotrush commented Aug 2, 2018

@Razorsheep i didn't find any good workaround, when deploying first time you just need to generate keys yourself and set valid access rights...

@edgareler

This comment has been minimized.

Copy link

edgareler commented Aug 15, 2018

In my case this issue happened on OAuth login tests when building on CircleCI. I fixed this issue and by generating the OAuth key pair.

steps:
  - run: openssl genrsa -out storage/oauth-private.key 4096
  - run: openssl rsa -in storage/oauth-private.key -pubout > storage/oauth-public.key

I added those steps before PHPUnit step.

@CJDennis

This comment has been minimized.

Copy link

CJDennis commented Aug 21, 2018

@edgareler Running those two commands at the command line worked for me.

@hmuntean-ro

This comment has been minimized.

Copy link

hmuntean-ro commented Sep 20, 2018

@hemorej you must set the owner of the keys to your web server. On mac this helped me

sudo chown _www:_www storage/oauth-*.key

@MrKriegler thanks for this command, it fixed my problem !

@bluesuiter

This comment has been minimized.

Copy link

bluesuiter commented Dec 24, 2018

If the file is not exist use the following cmd

php artisan passport:keys

Thank You buddy :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment