RE: Interoperable junctions on Linux

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

 



On Tue, 2013-04-23 at 16:24 +0000, Myklebust, Trond wrote:
> > -----Original Message-----
> > From: Simo Sorce [mailto:simo@xxxxxxxxxx]
> > Sent: Tuesday, April 23, 2013 12:20 PM
> > To: Myklebust, Trond
> > Cc: Chuck Lever; samba-technical@xxxxxxxxxxxxxxx; 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@xxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux