The hint is “unexpected return code 15 from connect.

IUCV CONNECT (see CP Programming Services) RC 15 is “no authorizations found”.  
(That’s needed for AF_IUCV sockets, too.)

The type of IUCV authorization depends on how the target virtual machine 
implements security. If the target has a configurable list of users it will 
talk to, the put IUCV ALLOW in its directory. 

If it doesn’t have anything like that, then put IUCV <target> in the origin 
user’s directory. 

Regards,
Alan

Alan Altmark
IBM Systems Lab Services
Endicott, NY         USA

> On Jul 13, 2022, at 3:01 PM, Mark Post <[email protected]> wrote:
> 
> On 7/13/22 01:48, Neale Ferguson wrote:
>> I built on RHEL 8 and, apart from tainting the kernel, I was able 
>> load/unload the kernel module without a problem. I did get:
>> 
>> depmod: ERROR: Bad version passed fsiucv
>> 
>> DJ - is there a message in /var/log/messages when you get the permission 
>> denied message? You may see a connect message and an IPRCODE.
> 
> I recompiled the module with DEBUG enabled, and I get this in dmesg:
> [337954.314039] fsiucv: Driver loaded for 1 connections
> [337954.314043] fsiucv: was allocated major number 247
> [337954.314095] fsiucv: iucv device control block: 00000000217fdf0a.d8
> [337954.314097] fsiucv: kernel device 0: 000000007d741f6a.1c8
> [337964.408114] fsiucv: prog_set - fsdev: 00000000217fdf0a count: 9
> [337975.711326] fsiucv: user_set - fsdev: 00000000217fdf0a count: 6
> [337992.351073] fsiucv: Device 0 at 00000000217fdf0a
> [337992.351079] fsiucv: fsiucv - user: MAINT
>                 node: ZVM6401
>                 data: \xd9\xc9\xe2\xc5\xd9\xe5\xc5\xd9\x15
> [337992.351136] fsiucv: unexpected rc 15 from connect
> [337992.351136] fsiucv: Connection severed
> [337992.351137] fsiucv: open complete - err: -13
> 
> I did have RISERVER running on MAINT on that z/VM system. Nothing showed
> up on the z/VM console, though. I'm not sure if MAINT has any of the
> "IUCV xxx" statements in the USER DIRECT, though, or if that is necessary.
> 
> And, for whatever reason, now that I have "#define FSIUCV_DEBUG    1" in
> the source, I can rmmod fsiucv after the failure with no problems. When
> I do that, this is what shows up in the log:
> [338235.665287] fsiucv: Deleting class device
> [338235.665301] fsiucv: Unregistering devices
> [338235.665302] fsiucv: Destroying device
> [338235.665423] fsiucv: removing group
> [338235.665435] fsiucv: freeing path
> [338235.665435] fsiucv: freeing input buffer
> [338235.665436] fsiucv: freeing output buffer
> [338235.665436] fsiucv: freeing answer buffer
> [338235.665436] fsiucv: cleaning up EIB queue
> [338235.665437] fsiucv: unregistering device
> [338235.665455] fsiucv: freeing iucv path
> [338235.665456] fsiucv: Unregistering driver
> [338235.665475] fsiucv: unregistering from iucv service -
> 000000002c3cae9d (000000009da3ed9e,0000000087090f3a)
> [338235.665479] fsiucv: freeing IUCV device control block
> 
> 
> Mark Post
> 
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO LINUX-390 or visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390 

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to