[Pkg-samba-maint] Bug#612764: I see the point they are looking for, the solution seems too limiting

[Steve Langasek]

reopen 612764
retitle 612764 reading "wide" symlinks fails with unix extensions enabled
tags 612764 upstream
thanks

On Mon, Feb 14, 2011 at 02:33:39AM +0100, Santiago Garcia Mantinan wrote:
> > then, a symlink pointing at /etc is pointing at the server's /etc, not the
> > client's /etc, and would give the wrong *contents*, wouldn't it?

> If you see it from the server's view yes, but seing it from the client, the
> client sees the link to /etc/ like a link to his /etc and used to follow it
> without any problem, now he gets the error I pasted at the bugreport.

> > In that case these wide links were already broken.  The behavior change has
> > just made the breakage more apparent.

> Nope, those links used to work before (note, chroot is really meant to be
> the client's real root).

> > BTW, is the powerpc thin client running with Unix extensions enabled or not?
> > If it is, shouldn't these symlinks be passed through for resolution on the
> > *client* side, making the problem moot?

> Yes, that's right, it is running with unix extensions, and is not able to
> read the contents of the symlink (not the file but the symlink itself) so it
> can't even try to follow it. This is the behaviour I don't understand.

Ok, if unix extensions are *enabled* on the client, then I think this is a
bug - possibly in the implementation of the security fix, possibly somewhere
else.  With unix extensions you're meant to be able to read the symlink *as
a symlink* - i.e., an inode that you can read the target off of.  Whether
it's a wide link or not should make no difference in a unix extensions
context.

So, reopening this bug.

> > Why don't you use NFS, which is natively designed for use as a Unix
> > filesystem?

> I've never been a friend of NFS, I've always disliked it having a portmapper
> and all that stuff around.

My personal opinion is that NFS would still be a better fit for your use
case.  NFS root gets much more attention and support than CIFS root does. :)

> > The point is that if Unix extensions are enabled on the server, you can
> > trigger an attack by making two connections with a client to get access to
> > arbritrary files on the filesystem.  First you connect with unix extensions
> > enabled on the client and create a symlink to your target file; then you
> > connect with unix extensions /disabled/ to trick the server into reading you
> > the contents of that file.

> In this case then we could allow wide links if the share is read only, for
> example (this would be my case), without having triggering any extra
> security problems.

Well, that's not a policy that Samba upstream can rely on.  read access to
/etc/passwd could still be considered a problem in a read-only context.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20110213/68e3d4d3/attachment.pgp>