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
