All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aurélien Aptel" <aaptel-IBi9RG/b67k@public.gmane.org>
To: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: cifs unable to access shares with read restricted at root level (bso#8950)
Date: Mon, 26 Oct 2015 13:54:30 +0100	[thread overview]
Message-ID: <20151026135430.255deac3@aaptelpc> (raw)
In-Reply-To: <20151026131817.3a8a3ded@aaptelpc>

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

I wanted to add a few things....

On Mon, 26 Oct 2015 13:18:17 +0100 Aurélien Aptel <aaptel-IBi9RG/b67k@public.gmane.org>
wrote:
> * How do you allocate a new dentry?  

That's too broad, forget this one. There are many functions to do that
depending on what you want.

> * What do d_obtain_alias() and d_splice_dentry() actually do? I've
> read the doc strings several times but I still have a hard time
> wrapping my head around it.  

To be more specific, where does d_obtain_alias() look for a dentry
associated with the provided inode? I would guess in all the connected
dentries for the inode superblock. If it's not there, what is the path
of the newly allocated dentry?

d_splice_alias() looks for an existing dentry associated with the
provided inode and if it founds one, replaces it with the one provided.
Correct?

Really, I think my biggest misunderstanding is, what does it mean for a
dentry to be disconnected?

> The result I'm getting seems to indicate that when an intermediary
> path element is inaccessible an alternate root dentry directly
> pointing to the requested path is created. The problem is that the
> prefixpath of that is not stored anywhere so when we ask for a
> pattern to list the content of that share, we use the path of the
> dentry from the root (which is, well /) instead of the share
> prefixpath.  

To illustrate this:

* User bill can only access HOST/share/sub/path and none of the
  intermediary path.

* When we mount this path to /mnt we realize we cannot access
  intermediary path.

* We create an alternative root which directly sores
  HOST/share/sub/path as / (but /sub/path/ is not stored anywhere!).

* When we ls /mnt, we use this alternate root path. The function that
  builds the share path from a dentry (build_path_from_dentry) simply
  walk the d_parent dentry until it reach /. In that case it immediatly
  stops because the disconnected root is.. a root. It should
  use /sub/path instead.

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG
Nürnberg)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-10-26 12:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-26 12:18 cifs unable to access shares with read restricted at root level (bso#8950) Aurélien Aptel
2015-10-26 12:54 ` Aurélien Aptel [this message]
2015-10-27  3:04 ` Shirish Pargaonkar
     [not found]   ` <CADT32eJgrjigh_ezCAJK-ivO-t_yygPEhgwoHKsE-8EdVxKP+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-27  9:59     ` Aurélien Aptel
2015-10-28  0:43       ` Shirish Pargaonkar
     [not found]         ` <CADT32eJrSGmKW4ksKMNKS1KAYDcN8UxLGPLfm8+Ag9mCxkNdYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-29 10:59           ` Aurélien Aptel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151026135430.255deac3@aaptelpc \
    --to=aaptel-ibi9rg/b67k@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.