bhyve: Add rfb unix socket access rights configuration

[quentin.thebault_defenso.fr]

Summary

Allow configuring the user, group and mode of the rfb unix socket to
make guest console access management easier. By default, the socket
remains created with the current bhyve process user and their group
as owners and a default mode of 0600.

Sponsored by: Defenso
MFC after: 2 weeks
Signed-off-by: Quentin Thébault <[e-mail]>

[quentin.thebault_defenso.fr]

usr.sbin/bhyve/bhyve.8

1021

@ziaee I had a little hesitation on whether to keep a space (switching back to No) after Ar mode here. I chose not to because that would be how we do it in standard English and it did not seem to hurt legibility. What do you think?

[ziaee]

usr.sbin/bhyve/bhyve.8

1021

Well, w= and h= right below use a space and a prose and, but we don't want to have one line of syntax also containing prose, right? That could easily be confusing.

Through the rest of the manual, we frequently do this. I think it's inefficient of space, but it's very clear:

.It Cm mode= Ns Ar mode
.It Cm uid= Ns Ar user
.It Cm gid= Ns Ar group
Access rights configuration for the UNIX socket.

However, I think what would make the most sense is to show it like on line 366.
So, can you specify any combination of these three attributes?
If one of them is required, I'd prefer something like this:

.It Xo
.Cm mode= Ns Ar mode Ns
.Oo Cm ,uid= Ns Ar user Oc Ns
.Oo Cm ,gid= Ns Ar group Oc
.Xc
Access rights configuration for the UNIX socket.

[novel]

usr.sbin/bhyve/bhyve.8

1024

Symbolic mode does not seem to play nice with the general device options because both are comma-separated, so it looks like modes like u=rwx,go=rx (as in chmod(1) examples) will not be processed properly.

1030

It is chown(8).

[markj]

This feature won't work with unprivileged bhyve, which can't change the owner and group of the file.

I don't really like it. This is not the only socket that bhyve creates, will we need to do this same thing for others? Why can't this be handled externally by whatever's invoking bhyve, or by setting bhyve's umask?

[quentin.thebault_defenso.fr]

In D60359#1389341, @markj wrote:

This feature won't work with unprivileged bhyve, which can't change the owner and group of the file.

I don't really like it. This is not the only socket that bhyve creates, will we need to do this same thing for others? Why can't this be handled externally by whatever's invoking bhyve, or by setting bhyve's umask?

Yeah... Reconsidering this from the point of view of the unprivileged bhyve work in progress it does not really seem to fit. I'll see with the vm-bhyve guys if we can implement the equivalent feature through that tool.

[quentin.thebault_defenso.fr]

usr.sbin/bhyve/bhyve.8

1021

Following @markj 's remark this will not be going through but I will keep in mind to use pure symbolic syntax and avoid mixing prose with it. Thanks for the feedback.

[markj]

In D60359#1390356, @quentin.thebault_defenso.fr wrote:

In D60359#1389341, @markj wrote:

This feature won't work with unprivileged bhyve, which can't change the owner and group of the file.

I don't really like it. This is not the only socket that bhyve creates, will we need to do this same thing for others? Why can't this be handled externally by whatever's invoking bhyve, or by setting bhyve's umask?

Yeah... Reconsidering this from the point of view of the unprivileged bhyve work in progress it does not really seem to fit. I'll see with the vm-bhyve guys if we can implement the equivalent feature through that tool.

Ok. To be clear, I am not saying "hard no", but so far it's not clear to me that this feature belongs in bhyve itself.

The unprivileged bhyve work is largely finished on main now, for what it's worth, there is no in-progress work that I'm aware of.