AI finds thousands of zero-day exploits... including in FreeBSD.

bakul · 2026-04-09T22:09:01+0100

iSCSI allows you to share physical storage but only *one* client (initiator) can access a given storage volume (LUN) while NFS allows more than one client to access the same file so even if you use an iSCSI device for NFS storage you still have the same security issues with NFS. Use of a proper capability design would allow secure access to network files but using it is nowhere near as easy as Unix's simplistic design of permission mode bits and shared password/group mapping.

MG · 2026-04-09T22:19:05+0100

OpenFreeNet said:
If there is security hole in NFS + Kerberos, the security hole does not depend from where NFS store the data: it can be a local device or a iSCSI device.

So a normal user can circumvent security-related features of iSCSI by sharing files from it via nfs? I think that contradicts the UNIX permission hierarchy, like a child cant have more permissions than its parent.

OpenFreeNet · 2026-04-09T22:30:23+0100

MG said:
So a normal user can circumvent security-related features of iSCSI by sharing files from it via nfs? I think that contradicts the UNIX permission hierarchy.

Code:

iSCSI ---> NFS service ---> NFS client

If iSCSI has no security holes, only the NFS service can see the data on the iSCSI device. But, if NFS has security holes, a non-authorized NFS client can receive data from the NFS service. iSCSI has no fault: it sends the data only to the NFS service, as configured.

MG · 2026-04-09T22:38:36+0100

OpenFreeNet said:
Code:

iSCSI ---> NFS service ---> NFS client

If iSCSI has no security holes, only the NFS service can see the data on the iSCSI device. But, if NFS has security holes, a non-authorized NFS client can receive data from the NFS service. iSCSI has no fault: it sends the data only to the NFS service, as configured.

Only if the user who configured nfs has more permissions than the user who mounted the iSCSI device. That's not on top of but 2 independent services.

OpenFreeNet · 2026-04-09T22:44:47+0100

MG said:
Only if the user who configured nfs has more permissions than the user who mounted the iSCSI device.

No, but at this point I give up. Maybe other users with more knowledge of iSCSI and/or NFS can explain better than me, or maybe I didn't understood some detail of this discussion. BTW, I never used iSCSI.

bakul · 2026-04-09T22:50:26+0100

MG said:
Only if the user who configured nfs has more permissions than the user who mounted the iSCSI device. That's not on top of but 2 independent services.

Device permissions have nothing to do with filesystem level permissions.

MG · 2026-04-09T22:57:03+0100

bakul said:
Device permissions have nothing to do with filesystem level permissions.

A user's permissions are device and file permissions, once set by root.
If a user has no access to a file in a iSCSI volume, neither has a nfs-server initiated by that user, sharing the same file (assuming it's somehow visible or manually referenced to without checking its existance). Permission denied with no explanation.

bakul · 2026-04-09T23:40:36+0100

OpenFreeNet said:
No, but at this point I give up.

Ditto.

cracauer@ · 2026-04-09T23:44:05+0100

OpenFreeNet said:
I never used network file systems, apart some sshfs connection, and minimal Samba setup, but they intrigue me a lot. CephFS, Garage, Seaweed, etc.. Or distribuited filesystems like IPFS and hyperdrive.

If you dislike the performance of NFS then you are in for a surprise with Ceph.

MG · 2026-04-10T03:04:48+0100

bakul said:
Ditto.

If user John mounted any filesystem and shares content in it using nfs, no other nfs user of that server can have more permissions on it than John has.
The security on the level of both services stays the same. Hence, running services on top of eachother makes sense. The 1st wall isn't going anywhere, regardless of the 2nd.