Re: sftp chroot requirements

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



Thank you.

I looked through some. If I search on chroot, then I get a lot of things. But no rationale.

So, where is the rationale?

Where is the rationale behind the fact that the final component of the chroot path should be owned by root? As I already said - and now I also assume you know about all and everything I ever said - I do not see any security risk in the final chroot component being owned by the user if it is not a shared chroot end-path.

I cannot find a rationale in the code. I cannot find it on 'the web'. Referring to some mailing lists is not helping. It does not state the rationale.

Please explain the rationale behind the safe_chroot path checking. And document it.

Why does the final component of the chroot path has to be owned by root?
What security issues - that I cannot think of - would arise if it is not owned by root?

Can I send in a patch?

Just referring people to 'you did not look, go look $maybehere' does not really help. Not receiving an answer would be better than your answer. You seem to have background knowledge. You seem to recall discussions about chroot. Where these discussions also about the _why_ the ownership of the final component of the chroot is supposed to be root?



Kind regards,
Stephan




On 02-05-15 00:23, Peter Stuge wrote:
Stephan Leemburg wrote:
I did not find any clues when 'googling' and could not find any search
options on the archives.
Try harder: http://marc.info/?l=openssh-unix-dev


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux