allowing a user to ireg files

[Leszek]

Hello group,

I'm trying to allow a normal irodsuser to register files with irods without actually loading them into the vault. The idea behind this is to avoid copying very large files over the network just to put/get them from irods, especially since the unix file system access control is enough for their purposes. What they need is extensive meta-data, hence the registering with irods.

I get a "PATH_REG_NOT_ALLOWED" Error when I try to ireg the file, even though I'm its owner, e.g.

ireg /gpfs_input/dataset.1000k.reads.fastq /TESTzone/home/tuser/dataset.1000k.reads.fastq
ERROR: regUtil: reg error for /TESTzone/home/tuser/dataset.1000k.reads.fastq, status = -129000 status = -129000 PATH_REG_NOT_ALLOWED

According to the manpage only the admins may do this, and the acNoChkFilePathPerm rule must be adapted to allow users as well. Only msiNoChkFilePathPerm seems to do the trick but that seems a bit excessive.

So I've tried to test this solution. There was no core.re in the directory server/config/reConfigs, so I simply made a new file and inserted "acNoChkFilePathPerm||msiNoChkFilePathPerm|nop" into it.
However, the server doesn't respond correctly anymore:

ERROR: _rcConnect: connectToRhost error, server on birke.rrz.uni-koeln.de:1247 is probably down status = -4115 SYS_HEADER_READ_LEN_ERR, Operation now in progress

Any ideas?

[John Constable]

On 4/29/16, 9:55 AM, "irod...@googlegroups.com on behalf of Leszek" <irod...@googlegroups.com on behalf of lnie...@gmail.com> wrote:

>
>
>So I've tried to test this solution. There was no core.re in the directory server/config/reConfigs, so I simply made a new file and inserted "acNoChkFilePathPerm||msiNoChkFilePathPerm|nop" into it.
>However, the server doesn't respond correctly anymore:
>
>ERROR: _rcConnect: connectToRhost error, server on birke.rrz.uni-koeln.de:1247 is probably down status = -4115 SYS_HEADER_READ_LEN_ERR, Operation now in progress
>
>Any ideas?

Assuming you’re using 4.1.8, the core.re files have moved to /etc/irods/, and perhaps putting the core.re where you have overrides the ’default’ core.re. You can actually add your own .re files in the /etc/irods/server_config.json I believe;

"re_rulebase_set": [
{
“filename”: “myrulebase"
"filename": "core"
}


Which will as I understand it look for /etc/irods/myrulebase.re. Any entries here will override those in the core.re and take precedence (but if they fail will go through to the core.re declaration of same)

This may allow you to debug the failures better and more easily include the changes you want.
My guess is the rule isn’t written quite correctly in the config file, and this has brought down the server.
As to why the system crashed, what do the logs say in /var/lib/irods/iRODS/server/logs/ ?

Hope that helps

John

[Leszek]

Thanks for the tip, indeed I'm using version 4.1.8 and I've found the core.re under /etc/irods. I've tried changing the file directly and the server behaved normally after a restart.

BTW, when anything is written in server/config/reConfig/core.re, even if it's just a comment sign (#) the server doesn't respond normally - it doesn't crash though and is still running - but it responds with the SYS_HEADER_READ_LEN_ERR. There are no specific error messages, just notices about the failed agent requests, like this:

Apr 29 14:11:45 pid:14383 NOTICE: rodsServer Release version rods4.1.8 - API Version d is up
Apr 29 14:11:45 pid:14386 NOTICE: Starting irodsReServer
Apr 29 14:11:45 pid:14383 ERROR: server_control_executor - icat_host_name is localhost, not a fqdn
Apr 29 14:11:45 pid:14383 NOTICE: >>> control plane :: listening on port 1248
Apr 29 14:11:45 pid:14383 NOTICE: Agent process 14386 exited with status 139 but not in queue

Now concerning the original problem, i.e. allowing users to ireg their own files, after reading about the current syntax, I've replaced the line acSetChkFilePathPerm {msiSetChkFilePathPerm("disallowPathReg"); } in core.re with:

acSetChkFilePathPerm {msiSetChkFilePathPerm("chkNonVaultPathPerm"); }

which is supposed to check UNIX ownership of the physical files and allow the registration within a vault if the vault path belongs to the user.
Unfortunately, this doesn't work:

init
ireg /gpfs_input/dataset.1000k.reads.fastq /TESTzone/home/tuser/dataset.1000k.reads.fastq
ERROR: regUtil: reg error for /TESTzone/home/tuser/dataset.1000k.reads.fastq, status = -1 status = -1 Unknown iRODS error, Operation not permitted

The server logs simply say "Agent exiting with status = 0". The file belongs to the testuser and is readable by all, and he can upload it with iput without a problem to the mentioned path, so it isn't a permission problem on either the UNIX or IRODS end. However, the ireg doesn't work.

Just to test it out, I've replaced the line with the unsecure option: acSetChkFilePathPerm {msiSetChkFilePathPerm("noChkPathPerm"); }
There's still an error:

ireg /gpfs_input/dataset.1000k.reads.fastq /TESTzone/home/tuser/dataset.1000k.reads.fastq
ERROR: regUtil: reg error for /TESTzone/home/tuser/dataset.1000k.reads.fastq, status = -516013 status = -516013 UNIX_FILE_STAT_ERR, Permission denied

Again, there are no significant errors logged in the logs, just that an Agent exitied with status 0. Any ideas?