From: Simo Sorce <simo@redhat.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
"samba-technical@lists.samba.org"
<samba-technical@lists.samba.org>,
fedfs-utils Developers <fedfs-utils-devel@oss.oracle.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Interoperable junctions on Linux
Date: Tue, 23 Apr 2013 12:19:32 -0400 [thread overview]
Message-ID: <1366733972.7239.66.camel@willson.li.ssimo.org> (raw)
In-Reply-To: <1366732290.35524.13.camel@leira.trondhjem.org>
On Tue, 2013-04-23 at 15:51 +0000, Myklebust, Trond wrote:
> On Tue, 2013-04-23 at 11:42 -0400, Chuck Lever wrote:
> > On Apr 23, 2013, at 10:51 AM, Simo Sorce <simo@redhat.com> wrote:
>
> > > Also why a xattr in the trusted namespace ? What are the security
> > > considerations that warrants a trusted attribute rather than a normal
> > > one ? (Links to RFCs or other docs are just fine)
> >
> > This is another historical design decision. If there is consensus that we don't need to protect junction metadata from unintended or malicious local changes, then we can put these in another namespace. However, without strong security here, redirecting network clients to another server and export can be hijacked, sending remote users to who knows where. Is it enough simply to insist that junctions be owned by root?
>
> Junctions resolve into mountpoints on clients. Allowing arbitrary users
> to change the junction parameters basically means giving them the
> ability to control the namespace on clients. They can for instance
> redirect an application from a trusted server onto an untrusted one.
>
> I therefore strongly recommend that we ensure the creation, deletion and
> modification of a junction remains a privileged operation on the server.
Is it not sufficient to make sure the symlink is owned by root ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
next prev parent reply other threads:[~2013-04-23 16:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-22 20:39 Interoperable junctions on Linux Chuck Lever
2013-04-23 14:51 ` Simo Sorce
2013-04-23 15:42 ` Chuck Lever
2013-04-23 15:51 ` Myklebust, Trond
2013-04-23 16:19 ` Simo Sorce [this message]
2013-04-23 16:24 ` Myklebust, Trond
2013-04-23 16:28 ` Simo Sorce
2013-04-23 16:30 ` Myklebust, Trond
2013-04-23 16:54 ` Simo Sorce
2013-04-23 18:11 ` Chuck Lever
2013-04-23 18:37 ` Simo Sorce
2013-04-23 18:43 ` Matt W. Benjamin
2013-04-23 19:52 ` Chuck Lever
2013-04-23 20:33 ` Simo Sorce
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=1366733972.7239.66.camel@willson.li.ssimo.org \
--to=simo@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=chuck.lever@oracle.com \
--cc=fedfs-utils-devel@oss.oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=samba-technical@lists.samba.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.