lack of security

Hi.

First of all, this 1980's era maillist should be ditched in favor of
GitHub-like collaboration for users. I wanted to submit a bugreport, but
instead had to go and adjust our mailer to suppress the greylisting and
holdoff ehlo timer because somehow yours mailer wants to show off his
manners. Set something up like bugzilla or github issues. Leave maillist
for coders/old people like yourself.

Now the issues I'm actually after.

1. Lack of security

With iSCSI, I have to supply a user and password.
With nvmetof-rdma, the only "shared secret" is the host nqn. This is
totally fine with me, except that for discovery, it automatically uses
that special nqn and with target configured to accept the "shared
secret" nqn, you get (as expected) the following on the target:

nvmet: connect by host nqn.2016-06.net.fused:node1 for subsystem
nqn.2014-08.org.nvmexpress.discovery not allowed

All guides out there suggest configuring nvmet wide-open. This isn't
what I want. More than that, I'd like to point out the current trend in
which companies started to prioritize security over performance.

This needs to be fixed in some way or another. Possibly allowing
discovery nqn to retrieve the directory, but denying connection to a
subsystem (or how do you call it -- I don't know the terminology).

2. block sizes wrong

# on target, an LV:
NAME                ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED
RQ-SIZE  RA WSAME
fused-random--disk0         0   4096      0    4096     512    1
   128 128    0B
# nvmeof on host:
nvme0n2         0    512      0     512     512    0 none      128 128    0B

As you see, minimal, optimal IO, physical sector size are all wrong. I
don't care much about rotating, but I would really care about optimal IO
as that's a hint to queue scheduler I guess.

There's no attribute to adjust in /subsystems/X/namespaces/Y to manually
set the values.

3. feature request.

I also wanted to store a custom string "attached" to a namespace, to
identify the blkdev I'm working with. I could get off with a serial, but
that's so UUID. I wanted to have something more humane.

Thanks.

--


_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme