> > > 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.
I guess I didn't make myself clear here, let's go to your statement of the two connections, furst with unix extensions on to create a symlink, if the share is read only, there is no way to create the symlink, so no way to get that read access to /etc/passwd, that's why I say that there would be no extra security problems enabling wide links with unix extensions enabled on a read only share. The only problem I see here is that a local user can make the symlink and then somebody without unix extensions can get read access to the file, but this happens also if you use wide links without unix extensions enabled, so this is happening with current implementation already. BTW: when you have a pointer to upstream's bug, ticket or whatever, can you share it here so that I can follow discussion? Thanks. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
