Interoperable junctions on Linux

Simo Sorce simo at redhat.com
Tue Apr 23 10:28:43 MDT 2013


On Tue, 2013-04-23 at 16:24 +0000, Myklebust, Trond wrote:
> > -----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?

Using fgetxattr() after an open and a fstat() ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the samba-technical mailing list