Enhancement: IPC file permission

[iFA88]

Greetings!
I run currently Parity-Ethereum/v2.0.6-stable-549e202-20180919/x86_64-linux-gnu/rustc1.29.0 with an unique Linux user and group. The client creates jsonrpc.ipc file into datadir with the permission 755.
Without write permission from other group I can not send any command to the socket.

It would be great, when I can set up the IPC file permissions with the CLI.

Many thanks!

[5chdn]

That's your task to set the proper permissions on unix sockets. Parity won't help you with that, sorry. Just write a small shell script if this is an annoyance.

[stone212]

@5chdn I agree that a setting like:

[ipc]
775

should be in Parity's domain. Because the parity binary creates the process and the process creates the ipc each time. The other ways to do this require invoking a parent process to call parity and change permissions and that is extra complication and it means that you can not use uniform systemd files (for example) on servers that require 755 and servers that require 775 permissions. Since it is a runtime-level and installation-level option (not a server-level option) the permissions should be controlled by the process IMO. Obviously adding people to a parity group or other things like this are not parity's responsibility.

[stone212]

@5chdn Has there been any change to this? Three people think it would be a good idea. Is there a reason against? I make the case why it is in Parity's domain in my previous comment.

[jam10o-new]

@stone212 can you elaborate a little bit on the type of usecase this kind of feature would be for, and why setting permissions on the directory the socket will live in (as I suggested here) is not an appropriate solution?

[stone212]

Hi @joshua-mir well I already did explain why that is not an appropriate solution in my comment above but let me give some more explanations.

1. Because parity creates the file, it is parity that should control how that file manifests.

2. If two different processes have automated control over a file they could have competing agendas

3. With your suggestion you have to have two sets of tools working on the same file (meaning more things to update/maintain) and - this is critical -

4. one of them is already subservient to the other. This means a script has to monitor parity to see if it has done anything to remove/re-add/modify that file so it is more than just a simple @reboot cron job.

This (4) is the most important. Since parity creates the file and since parity can remove or re-surrect the file - even accidentally - it is very complicated to have a script that always modifies this file in any of the situation where parity might re-create it. And what if you run Parity as a systemd process, or a cron job? Your script then has to monitor the systemd process? (Obviously you want this to be an option and sometimes a person will not add

[ipc]
775

to the config.toml file because the person wants to write a custom script. But with this solution, it makes sure that any time parity creates the file it creates the file the way you want it created with zero seconds of downtime.

Okay so I will answer your first question. The use case is a blockchain explorer that uses IPC to communicate with the node, but I want to run it as a different user than I run parity as.

[stone212]

@joshua-mir Oh another reason is because I automate dozens of Parity nodes with a central control script. They all have different config.toml files but all of them can be automated because all variables in the parity configuration (and I consider the IPC file to be part of Parity's configuration) are controlled in this file. So the updates are automatic but they would not be if I have one or two nodes that need custom scripts to control parts of Parity.

[yxliang01]

Nice arguments @stone212 , I am also supporting that this should be in Parity's domain.

[yxliang01]

Interesting. I thought it's simply a function call to set the file permission and it's pretty much. 😂 But, at least, good to know that this is being considered. 🎉

[stone212]

@seunlanlege I also thought it was simple but thank you for self-assigning. I think as Parity grows in use cases and there are abstractions layered on top of a Parity server this will be very important, and it is already important to some people.

[ethernomad]

This would be very useful. It's awkward to do this in .service file because you have to somehow wait for the file to be created before you can set the correct permissions.

[stone212]

@ordian This is really great news but you closed this without answering the original Issue. Is the method to do this now like this in the command line:

			"--ipc-chmod=[NUM]",
			"Specify octal value for ipc socket permissions (unix/bsd only)",

And like this (example) in the config.toml:

[ipc]
chmod = "660"
disable = false
path = "$HOME/.parity/jsonrpc.ipc"
apis = ["web3", "eth", "net", "parity", "parity_accounts", "personal", "traces", "rpc", "secretstore"]

[dvdplm]

It’s not in a release yet and documentation is forthcoming (/cc @seunlanlege ).

[stone212]

@dvdplm That was my point. "forthcoming" != "complete".

I do not mean to criticize the excellent work! Just a clerical point that I made, and I added info I found into this thread because I know how terrible it is when you see an Issue is closed but you still do not have what you need to solve the issue you are having.

[stone212]

comment deleted

Documentation found at: https://wiki.parity.io/Configuring-Parity-Ethereum.html

Very happy to see this! Thank you to everyone who worked on this.