Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228031 > unrolled thread

Qemu 9pfs sftp chrootdirectory option issue

Back to article view | Back to linux.debian.user

Contents

  Qemu 9pfs sftp chrootdirectory option issue john doe <johndoe65534@mail.com> - 2020-10-20 18:50 +0200
    Re: Qemu 9pfs sftp chrootdirectory option issue Markus Schönhaber <debian-user@list-post.mks-mail.de> - 2020-10-20 20:10 +0200
      Re: Qemu 9pfs sftp chrootdirectory option issue john doe <johndoe65534@mail.com> - 2020-10-21 19:20 +0200
        Re: Qemu 9pfs sftp chrootdirectory option issue Markus Schönhaber <debian-user@list-post.mks-mail.de> - 2020-10-21 23:10 +0200
          Re: Qemu 9pfs sftp chrootdirectory option issue john doe <johndoe65534@mail.com> - 2020-10-28 18:40 +0100
            Re: Qemu 9pfs sftp chrootdirectory option issue Markus Schönhaber <debian-user@list-post.mks-mail.de> - 2020-10-28 19:00 +0100
              Re: Qemu 9pfs sftp chrootdirectory option issue john doe <johndoe65534@mail.com> - 2020-10-28 19:30 +0100
                Re: Qemu 9pfs sftp chrootdirectory option issue Markus Schönhaber <debian-user@list-post.mks-mail.de> - 2020-10-28 20:00 +0100
                  Re: Qemu 9pfs sftp chrootdirectory option issue john doe <johndoe65534@mail.com> - 2020-10-28 20:10 +0100
                    Re: Qemu 9pfs sftp chrootdirectory option issue john doe <johndoe65534@mail.com> - 2020-11-09 10:00 +0100

#228031 — Qemu 9pfs sftp chrootdirectory option issue

Debians,

According to (1):

"ChrootDirectory
Specifies a path to chroot(2) to after authentication. This path, and
all its components, must be root-owned directories that are not writable
by any other user or group. After the chroot, sshd(8)"


i'm using the Qemu's 9p implimentation (mapped mode) to share files
between guests and host, (2) due to lack of space on the guest.
This mountpointis not owned by root and I'm  at a lost on how to have
sftp access to that guest while pointing the chroot directory directive
to that share.


Has anyone been able to set up the chrootdirectory directive with a 9p
share?
If yes, how is the host and the guest configured.

Any ideas on other approaches are also welcome.


1) https://linux.die.net/man/5/sshd_config
2) https://wiki.qemu.org/Documentation/9psetup

--
John Doe

[toc] | [next] | [standalone]

#228036

20.10.20, 18:49 +0200, john doe:

> Debians,
> 
> According to (1):
> 
> "ChrootDirectory
> Specifies a path to chroot(2) to after authentication. This path, and
> all its components, must be root-owned directories that are not writable
> by any other user or group. After the chroot, sshd(8)"
> 
> 
> i'm using the Qemu's 9p implimentation (mapped mode) to share files
> between guests and host, (2) due to lack of space on the guest.
> This mountpointis not owned by root and I'm  at a lost on how to have
> sftp access to that guest while pointing the chroot directory directive
> to that share.

How about moving the 9pshare to a root-owned directory and pointing the
ChrootDirectory there, for example:
share -> /all/owned/by/root/9pshare
ChrootDirectory -> /all/owned/by/root

-- 
Regards
  mks

[toc] | [prev] | [next] | [standalone]

#228075

On 10/20/2020 7:59 PM, Markus Schönhaber wrote:
> 20.10.20, 18:49 +0200, john doe:
>
>> Debians,
>>
>> According to (1):
>>
>> "ChrootDirectory
>> Specifies a path to chroot(2) to after authentication. This path, and
>> all its components, must be root-owned directories that are not writable
>> by any other user or group. After the chroot, sshd(8)"
>>
>>
>> i'm using the Qemu's 9p implimentation (mapped mode) to share files
>> between guests and host, (2) due to lack of space on the guest.
>> This mountpointis not owned by root and I'm  at a lost on how to have
>> sftp access to that guest while pointing the chroot directory directive
>> to that share.
>
> How about moving the 9pshare to a root-owned directory and pointing the
> ChrootDirectory there, for example:
> share -> /all/owned/by/root/9pshare
> ChrootDirectory -> /all/owned/by/root
>

Thank you for this.

I can only do that if 'passthrough' is used, as I don't realy understand
the implecations of running qemu as root, I was hoping to find a way
with 'mapped'.
'mapped' requires that the directory on the host is set to the group and
user used by qemu, 'libvirt-qemu in this case.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#228085

21.10.20, 19:11 +0200, john doe:

> On 10/20/2020 7:59 PM, Markus Schönhaber wrote:

>> How about moving the 9pshare to a root-owned directory and pointing the
>> ChrootDirectory there, for example:
>> share -> /all/owned/by/root/9pshare
>> ChrootDirectory -> /all/owned/by/root
>>
> 
> Thank you for this.
> 
> I can only do that if 'passthrough' is used, as I don't realy understand
> the implecations of running qemu as root, I was hoping to find a way
> with 'mapped'.
> 'mapped' requires that the directory on the host is set to the group and
> user used by qemu, 'libvirt-qemu in this case.

I don't see the problem with chown'ing the 9pshare directory to the qemu
user in my example above.

-- 
Regards
  mks

[toc] | [prev] | [next] | [standalone]

#228362

On 10/21/2020 11:02 PM, Markus Schönhaber wrote:
> 21.10.20, 19:11 +0200, john doe:
>
>> On 10/20/2020 7:59 PM, Markus Schönhaber wrote:
>
>>> How about moving the 9pshare to a root-owned directory and pointing the
>>> ChrootDirectory there, for example:
>>> share -> /all/owned/by/root/9pshare
>>> ChrootDirectory -> /all/owned/by/root
>>>
>>
>> Thank you for this.
>>
>> I can only do that if 'passthrough' is used, as I don't realy understand
>> the implecations of running qemu as root, I was hoping to find a way
>> with 'mapped'.
>> 'mapped' requires that the directory on the host is set to the group and
>> user used by qemu, 'libvirt-qemu in this case.
>
> I don't see the problem with chown'ing the 9pshare directory to the qemu
> user in my example above.
>

Okay, following your instructions I can now connect using sftp but I can
not access the content of the share:

$ ls -dl /srv/sftp/9p
drwx------ 8 root root ... /srv/sftp/9p
$ sftp sftp9p
Connected to sftp9p.
sftp> ls
remote readdir("/"): Permission denied
sftp> quit


I don't understand how I can have both working together.

How do you manage to get it working?

--
John Doe

[toc] | [prev] | [next] | [standalone]

#228363

28.10.20, 18:30 +0100 john doe:

> On 10/21/2020 11:02 PM, Markus Schönhaber wrote:
>> 21.10.20, 19:11 +0200, john doe:
>>
>>> On 10/20/2020 7:59 PM, Markus Schönhaber wrote:
>>
>>>> How about moving the 9pshare to a root-owned directory and pointing the
>>>> ChrootDirectory there, for example:
>>>> share -> /all/owned/by/root/9pshare
>>>> ChrootDirectory -> /all/owned/by/root
>>>>
>>>
>>> Thank you for this.
>>>
>>> I can only do that if 'passthrough' is used, as I don't realy understand
>>> the implecations of running qemu as root, I was hoping to find a way
>>> with 'mapped'.
>>> 'mapped' requires that the directory on the host is set to the group and
>>> user used by qemu, 'libvirt-qemu in this case.
>>
>> I don't see the problem with chown'ing the 9pshare directory to the qemu
>> user in my example above.
>>
>
> Okay, following your instructions I can now connect using sftp but I can
> not access the content of the share:

No, you seemingly didn't follow what I said.

> $ ls -dl /srv/sftp/9p
> drwx------ 8 root root ... /srv/sftp/9p

Isn't "9p" supposed to be the share directory? If it is, why is it owned
by root and has these restrictive permissions?

Assuming
ChrootDirectory -> /srv/sftp -> make this root:root, drwxr-xr-x
share -> /srv/sftp/9p -> make this libvirt-qemu:libvirt-qemu, drwxr-xr-x

> $ sftp sftp9p
> Connected to sftp9p.
> sftp> ls
> remote readdir("/"): Permission denied

Of course. Guessing from what you wrote above, only root can even list
the directory's contents (or change into it, in the first place).

-- 
Regards
  mks

[toc] | [prev] | [next] | [standalone]

#228365

On 10/28/2020 6:51 PM, Markus Schönhaber wrote:
> 28.10.20, 18:30 +0100 john doe:
>
>> On 10/21/2020 11:02 PM, Markus Schönhaber wrote:
>>> 21.10.20, 19:11 +0200, john doe:
>>>
>>>> On 10/20/2020 7:59 PM, Markus Schönhaber wrote:
>>>
>>>>> How about moving the 9pshare to a root-owned directory and pointing the
>>>>> ChrootDirectory there, for example:
>>>>> share -> /all/owned/by/root/9pshare
>>>>> ChrootDirectory -> /all/owned/by/root
>>>>>
>>>>
>>>> Thank you for this.
>>>>
>>>> I can only do that if 'passthrough' is used, as I don't realy understand
>>>> the implecations of running qemu as root, I was hoping to find a way
>>>> with 'mapped'.
>>>> 'mapped' requires that the directory on the host is set to the group and
>>>> user used by qemu, 'libvirt-qemu in this case.
>>>
>>> I don't see the problem with chown'ing the 9pshare directory to the qemu
>>> user in my example above.
>>>
>>
>> Okay, following your instructions I can now connect using sftp but I can
>> not access the content of the share:
>
> No, you seemingly didn't follow what I said.
>

On the host, the directory to be exported is set to
libvirt-qemu:libvirt-qemu.

In the guest, if I set the mount point to libvirt-qemu:libvirt-qemu, I
get the following error:

"fatal: bad ownership or modes for chroot directory "/srv/sftp/9p""


the above error is triggered by the chrootdirectory directive which
requires 'root:root 0700' as ownership and mode.

 From (1):

"ChrootDirectory
Specifies a path to chroot(2) to after authentication. This path, and
all its components, must be root-owned directories that are not writable
by any other user or group. After the chroot, sshd(8)"

>> $ ls -dl /srv/sftp/9p
>> drwx------ 8 root root ... /srv/sftp/9p
>
> Isn't "9p" supposed to be the share directory? If it is, why is it owned
> by root and has these restrictive permissions?
>

Because of the chrootdirectory directive (see above).

> Assuming
> ChrootDirectory -> /srv/sftp -> make this root:root, drwxr-xr-x
> share -> /srv/sftp/9p -> make this libvirt-qemu:libvirt-qemu, drwxr-xr-x
>

If I do that, I can't even connect to the sftp server:

$ sftp sftp9p
packet_write_wait: Connection to ::1 port 22: Broken pipe
Connection closed

>> $ sftp sftp9p
>> Connected to sftp9p.
>> sftp> ls
>> remote readdir("/"): Permission denied
>
> Of course. Guessing from what you wrote above, only root can even list
> the directory's contents (or change into it, in the first place).
>

No argument there.


I appriciate your help/feedback.


1)  https://linux.die.net/man/5/sshd_config

--
John Doe

[toc] | [prev] | [next] | [standalone]

#228367

28.10.20, 19:19 +0100 john doe:

> On 10/28/2020 6:51 PM, Markus Schönhaber wrote:
>> 28.10.20, 18:30 +0100 john doe:
> 
>>> $ ls -dl /srv/sftp/9p
>>> drwx------ 8 root root ... /srv/sftp/9p
>>
>> Isn't "9p" supposed to be the share directory? If it is, why is it owned
>> by root and has these restrictive permissions?
>>
> 
> Because of the chrootdirectory directive (see above).

That's why I suggested (twice!) to set the ChrootDirectory to the
directory that *contains* the share directory.

>> Assuming
>> ChrootDirectory -> /srv/sftp -> make this root:root, drwxr-xr-x
>> share -> /srv/sftp/9p -> make this libvirt-qemu:libvirt-qemu, drwxr-xr-x
>>
> 
> If I do that, I can't even connect to the sftp server:
> 
> $ sftp sftp9p
> packet_write_wait: Connection to ::1 port 22: Broken pipe
> Connection closed

The logs will probably tell you what exactly is wrong.

-- 
Regards
  mks

[toc] | [prev] | [next] | [standalone]

#228368

On 10/28/2020 7:50 PM, Markus Schönhaber wrote:
> 28.10.20, 19:19 +0100 john doe:
>
>> On 10/28/2020 6:51 PM, Markus Schönhaber wrote:
>>> 28.10.20, 18:30 +0100 john doe:
>>
>>>> $ ls -dl /srv/sftp/9p
>>>> drwx------ 8 root root ... /srv/sftp/9p
>>>
>>> Isn't "9p" supposed to be the share directory? If it is, why is it owned
>>> by root and has these restrictive permissions?
>>>
>>
>> Because of the chrootdirectory directive (see above).
>
> That's why I suggested (twice!) to set the ChrootDirectory to the
> directory that *contains* the share directory.
>
>>> Assuming
>>> ChrootDirectory -> /srv/sftp -> make this root:root, drwxr-xr-x
>>> share -> /srv/sftp/9p -> make this libvirt-qemu:libvirt-qemu, drwxr-xr-x
>>>
>>
>> If I do that, I can't even connect to the sftp server:
>>
>> $ sftp sftp9p
>> packet_write_wait: Connection to ::1 port 22: Broken pipe
>> Connection closed
>
> The logs will probably tell you what exactly is wrong.
>

Yes the cause of this message is explained by the fatal message
mentioned in my privious e-mail.

As I'm not able to properly describe the issue I'm facing I will need to
come at this from an other angle.

Thanks anyway for your help.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#228524

On 10/28/2020 8:00 PM, john doe wrote:
> On 10/28/2020 7:50 PM, Markus Schönhaber wrote:
>> 28.10.20, 19:19 +0100 john doe:
>>
>>> On 10/28/2020 6:51 PM, Markus Schönhaber wrote:
>>>> 28.10.20, 18:30 +0100 john doe:
>>>
>>>>> $ ls -dl /srv/sftp/9p
>>>>> drwx------ 8 root root ... /srv/sftp/9p
>>>>
>>>> Isn't "9p" supposed to be the share directory? If it is, why is it
>>>> owned
>>>> by root and has these restrictive permissions?
>>>>
>>>
>>> Because of the chrootdirectory directive (see above).
>>
>> That's why I suggested (twice!) to set the ChrootDirectory to the
>> directory that *contains* the share directory.
>>
>>>> Assuming
>>>> ChrootDirectory -> /srv/sftp -> make this root:root, drwxr-xr-x
>>>> share -> /srv/sftp/9p -> make this libvirt-qemu:libvirt-qemu,
>>>> drwxr-xr-x
>>>>
>>>
>>> If I do that, I can't even connect to the sftp server:
>>>
>>> $ sftp sftp9p
>>> packet_write_wait: Connection to ::1 port 22: Broken pipe
>>> Connection closed
>>
>> The logs will probably tell you what exactly is wrong.
>>
>
> Yes the cause of this message is explained by the fatal message
> mentioned in my privious e-mail.
>
> As I'm not able to properly describe the issue I'm facing I will need to
> come at this from an other angle.
>
> Thanks anyway for your help.
>

I managed to get it working by pointing the 'chrootdirective' to a root
own directory, then by mounting the 9p share in a subdirectory of that
directory.
I use the '-d' option to the 'internal-sftp' to make it transparent to
the users connecting to that VM.:


$ cat /etc/ssh/sshd_config
Match ...
         ChrootDirectory /mnt/sftp
         ForceCommand internal-sftp -d sftp

$ls -dl /mnt/sftp
drwxr-xr-x 3 root root 4096 ... /mnt/sftp

$ cat /etc/fstab
sftp_dir /mnt/sftp/sftp 9p trans=virtio,version=9p2000.L

$ ls -dl /mnt/sftp/sftp
drwxr-xrwx 2 64055 64055 4096 ... /mnt/sftp/sftp

Note that I still have not figured out why I need to sed the permission
for 'other' to 'rwx' for it to work or how to restrict access to the
share to a specific 'group'.


On the host I would invoke virt-install as follow:

virt-install --filesystem
type=mount,mode=mapped,source=/mnt/sftp,target=sftp_dir


Thanks to 'Markus Schönhaber <debian-user@list-post.mks-mail.de>' for
his input and for putting me on the right track.

--
John Doe

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web