global install fails: sub-install of icu4c-data@56l runs unprivileged

[geonanorch]

I just struggled to install full-icu on a fresh Ubuntu 16.04 system with node v6.11.2 (npm v3.10.10). Node was installed using the official instructions.

The error I got was:

root@frondev:~# npm install -g full-icu
/usr/bin/node-full-icu-path -> /usr/lib/node_modules/full-icu/node-icu-data.js

> full-icu@1.2.0 postinstall /usr/lib/node_modules/full-icu
> node postinstall.js

npm install icu4c-data@56l (Node 6.11.2 and small-icu 56.1) -> icudt56l.dat
full-icu$ /usr/bin/nodejs /usr/lib/node_modules/npm/bin/npm-cli.js install icu4c-data@56l
npm ERR! Linux 4.4.0-87-generic
npm ERR! argv "/usr/bin/nodejs" "/usr/lib/node_modules/npm/bin/npm-cli.js" "install" "icu4c-data@56l"
npm ERR! node v6.11.2
npm ERR! npm  v3.10.10
npm ERR! path /root/.npm/icu4c-data/0.56.2/package
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall mkdir

npm ERR! Error: EACCES: permission denied, mkdir '/root/.npm/icu4c-data/0.56.2/package'
npm ERR!     at Error (native)
npm ERR!  { Error: EACCES: permission denied, mkdir '/root/.npm/icu4c-data/0.56.2/package'
npm ERR!     at Error (native)
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'mkdir',
npm ERR!   path: '/root/.npm/icu4c-data/0.56.2/package' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.

After opening permissions for the required directories, the installation of package icu4c-data proceeds further, and I can see that files are created with owner nobody. There is also no issue when installing locally (unprivileged user). Finally installing icu4c-data globally with a standalone npm install -g icu4c-data@56l works as well!

I am not familiar enough with npm to pinpoint the issue, I just saw from its configuration that there is a mechanism for switching user when running in privileged/global mode. I was eventually able to install with the following workaround (running as root); note the owner compared with other global modules:

npm set -g unsafe-perm
npm install -g full-icu
npm set -g unsafe-perm false

root@frondev:~# ll /usr/lib/node_modules/
total 32
drwxr-xr-x  8 root   root 4096 Aug 24 12:56 ./
drwxr-xr-x 55 root   root 4096 Aug 24 11:07 ../
drwxr-xr-x  2 nobody root 4096 Aug 24 11:25 commander/
drwxr-xr-x  2 root   root 4096 Aug 24 12:56 full-icu/
drwxr-xr-x  2 root   root 4096 Aug 24 12:56 icu4c-data/
drwxr-xr-x  5 nobody root 4096 Aug 24 11:39 mjml/
drwxr-xr-x  7 nobody root 4096 Aug 24 11:30 nodemon/
drwxr-xr-x 11 root   root 4096 Aug 24 11:07 npm/

[srl295]

@geonanorch thanks for this comment. I think at this point, probably adding this instruction to the readme may be the best, or even if the mkdir fails.

[johana-star]

Do you understand why the user that runs npm install is not the actor that initiates this directory creation? I've run a sudo npm install and still had an error, which took me to this issue… This could be some subtle issue within npm or with your code…? Hard to say, and like @geonanorch I'm not well-versed enough to figure out exactly why this doesn't work, but I suspect the issue is directly related to the fact that a childprocess is responsible for the directory creation.

@iarna When a childprocess is started by an npm script run by root, should that childprocess have elevated privileges? If so, I'm glad to file a node or npm issue, tho I'd appreciate being pointed to the most appropriate repo.

Edited to add: I'm on MacOS, this may be a POSIX-specific issue.

[johana-star]

After reviewing the child_process#spawnSync command, I believe this issue is caused because a UID options argument was not included in the call.

I think that revising it to include something like uid: process.getuid() will allow the child process to impersonate its parent process and remove the necessity for a workaround. I'm going to try it out and if successful will issue a PR.

[srl295]

@strand thanks for the investigation, your analysis sounds reasonable. I'd be glad to accept a PR for this.

[johana-star]

Not quite sure what I'm doing wrong in my local environ, but I'm not having no success at verifying that the copy of full-icu I am installing is the local version… I've added console log statements to the code as a reality check, however, running sudo npm install ../full-icu-np from the project which depends on full-icu does not reveal these statements getting logged to the console.

@srl295, would you take a stab at this, or have you been unable to repro the error?

[johana-star]

I think I figured out what the confusion is… full-icu is not a direct dep of the project I was in, I'll see about creating the simplest repro possible.

My direct dep is luxon and full-icu is a dep of that. However, luxon and full-icu correctly install in an empty directory. 🤔

[johana-star]

I attempted to determine how this error was introduced by using git bisect and sudo rm -rf node_modules && npm install to test commits between the introduction of luxon to our project and HEAD… However, this seems to have twiddled whatever state caused the error in the first place, as I can no longer reproduce.

I suspect that a poorly timed ctrl-c left the node_modules in a dirty state, but that's a guess.

[iarna]

@strand npm drops permissions when spawning child processes. It runs child processes as the user nobody. This makes build steps when running as root borderline useless. It's long been a pet peeve of mine about npm.

Ditching this behavior is on my roadmap for npm@7, but that old behavior will be with us for a while yet, unfortunately.

[prantlf]

If you use nvm to install node, there will be no problem, because the node installation directory is in user's ~/.nvm. It can be a natural workaround, if multiple node versions are needed to be installed.

[pierophp]

I did this workaround on my Dockerfile, to install as "global":

RUN mkdir /usr/local/etc/full-icu
RUN cd /usr/local/etc/full-icu && yarn add full-icu
ENV NODE_ICU_DATA=/usr/local/etc/full-icu/node_modules/full-icu

[andy-weinstein]

On my Mac, having experienced the same issue, I took what pierophp did above for Docker and just did:
cd /usr/local/etc
mkdir full-icu
cd full-icu
npm install full-icu

and it worked, finally. Thanks pierophp and everybody else for helping

[srl295]

@andy-weinstein @pierophp OK, so you are not installing globally but in a sub module.

Any suggestions on wording here? Can I improve the docs? Would you like to open a PR?

[andy-weinstein]

Thanks for being in touch. While I am an experienced developer in general, I am a newbee (sp?) in the world of nodejs, javascript, and the alexa cli sdk. I'm wanted to get Luxon working with my skill. Luxon said that for some of its functionality, full-icu was needed and that it was a little tricky to work with. I did succeed in installing globally using the method I mentioned, which I found in that forum after doing what Luxon suggested didn't work (though they do sort of warn you that it's not going to be simple: https://moment.github.io/luxon/docs/manual/install.html). But this didn't end up actually solving my larger issue, because as you say, basically I need full-icu as a sub-module because Luxon wants it. But when I do an "ask deploy/", it does not end up putting full-icu in the node-modules directory that I think it zips up and deploys to the server, and so the whole thing doesn't work. As I said, I'm kind of new to this stuff, so I abstractly understand the issue, and I could imagine that the solution would either be for the ask cli to be smarter about finding implicit dependencies on global packages, or alternatively that full-icu would nicely support installing locally into my skill. But I don't really know what exactly has to happen for me to get the end result I want. In the meantime I found a workaround for the particular issue I was dealing with using standard JS, so I'm not stuck. But I'm sure people will want to be able to use Luxon and full-icu with the Alexa CLI, and it's not clear (to me) how to get that to work. Thanks, Andy

…

On Tue, Oct 29, 2019 at 4:34 PM Steven R. Loomis ***@***.***> wrote: @andy-weinstein <https://github.com/andy-weinstein> @pierophp <https://github.com/pierophp> OK, so you are not installing globally but in a sub module. Any suggestions on wording here? Can I improve the docs? Would you like to open a PR? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANT5FOMQ6BFXD3JMKM2SANDQRBCYJANCNFSM4DYE4VRA> .

[srl295]

@andy-weinstein yes, it is tricky, more than it ought to be. That's why in Node.js 13 I worked to make full ICU the default — so hopefully you can avoid worrying about this in the future.

Here's the way to think about it: your real goal is to get the exact appropriate data file ( icudt**.dat) loaded on disk. npm i full-icu is intended to be a convenience method for doing that. It works in some situations. But not all.

What I would say is: make sure to re-run npm i full-icu every time the node binary changes (i.e. switching version, some upgrade, etc). That will make sure the data contents are up to date.