Interoperable junctions on Linux

Myklebust, Trond Trond.Myklebust at netapp.com
Tue Apr 23 10:24:08 MDT 2013


> -----Original Message-----
> From: Simo Sorce [mailto:simo at redhat.com]
> Sent: Tuesday, April 23, 2013 12:20 PM
> To: Myklebust, Trond
> Cc: Chuck Lever; samba-technical at lists.samba.org; fedfs-utils Developers;
> Linux NFS Mailing List
> Subject: Re: Interoperable junctions on Linux
> 
> 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 at 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 ?

How do you check that atomically with the getxattr?

Trond


More information about the samba-technical mailing list