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

[Santiago Garcia Mantinan]

> I don't think the config file is the right place to document this.  It is
> documented in the smb.conf manpage that these options are incompatible.

I meant to write a security warning in the config if they were not
incompatible, now that they are incompatible of course that is not needed.

> But I don't understand how disabling wide links breaks anything for you in
> this case.  I guess your exported share is a chrooted powerpc tree, and
> you're not exporting the actual root filesystem of the server, right?  So

Right.

> 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).

> 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.

> 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.

> 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.

On the other hand, if you have unix extensions disabled you can use wide
links and then a local user can make the symlink and then it's content would
be available through the share.

I think that there must be some other way to cut this out while leaving the
symlinks readable (not the contents of the file they point to) for clients
like mine.

I hope you know understand how this breaks clients like mine.

Regards...
-- 
Manty/BestiaTester -> http://manty.net