A file is chmod 600. It gets opened on Windows, and it gets changed to 644. Now the secrets are exposed to all users. This is bad! This happens if the user does: N:\> echo foobar > secretfile But it does stay at chmod 600 if he does (append instead of truncate): N:\> echo foobar >> secretfile Why does this happen? The "create mask" parameter is set to 644. I do not think this should apply to files that already exist, but only to files that are created. Samba version is 2.2.8a.
Of course '>' is very different of '>>'. '>' creates a new file so THE NEW secretfile is created with the 644 mask. '>>' appends in the file. If you do this twice w/ '>>' you will see this: foobar foobar But if you do the same twice but with '>': foobar Only once 'cause the file is created twice. Cheers> A file is chmod 600. It gets opened on Windows, and it gets > changed to 644. > This happens if the user does: > N:\> echo foobar > secretfile > But it does stay at chmod 600 if he does (append instead of truncate): > N:\> echo foobar >> secretfile > The "create mask" parameter is set to 644. I do not think this
The '>' creates a new file, but ONLY if the file did NOT exist before. If it does exist, the file's contents are replaced, but it still the same file. This is the way it works on both Windows and Unix. This command: echo foobar > secretfile Does not clobber the permissions (or NTFS ACLs) on Unix (or Windows). But it does clobber them when Samba is involved. It makes no sense to say that the act of editting a text file has any effect on its security permissions. (Whether it be in notepad.exe or on the command line as I have shown.) -----Original Message----- From: juanjo.carel@ono.com [mailto:juanjo.carel@ono.com] Sent: Thursday, January 15, 2004 3:40 AM Of course '>' is very different of '>>'. '>' creates a new file so THE NEW secretfile is created with the 644 mask. '>>' appends in the file.> A file is chmod 600. It gets opened on Windows, and it gets > changed to 644. > This happens if the user does: > N:\> echo foobar > secretfile > But it does stay at chmod 600 if he does (append instead of truncate): > N:\> echo foobar >> secretfile > The "create mask" parameter is set to 644. I do not think this
Update: This effect only seem to happen if the file's name begins with a dot, e.g. ".secretfile" It does not happen for "secretfile" as I have previously claimed. -----Original Message----- From: Panko, Kevin [mailto:kevin.panko@pw.utc.com] Sent: Thursday, January 15, 2004 10:55 AM To: samba@lists.samba.org Subject: RE: [Samba] permission bits clobbered The '>' creates a new file, but ONLY if the file did NOT exist before. If it does exist, the file's contents are replaced, but it still the same file. This is the way it works on both Windows and Unix. This command: echo foobar > secretfile Does not clobber the permissions (or NTFS ACLs) on Unix (or Windows). But it does clobber them when Samba is involved. It makes no sense to say that the act of editting a text file has any effect on its security permissions. (Whether it be in notepad.exe or on the command line as I have shown.) -----Original Message----- From: juanjo.carel@ono.com [mailto:juanjo.carel@ono.com] Sent: Thursday, January 15, 2004 3:40 AM Of course '>' is very different of '>>'. '>' creates a new file so THE NEW secretfile is created with the 644 mask. '>>' appends in the file.> A file is chmod 600. It gets opened on Windows, and it gets > changed to 644. > This happens if the user does: > N:\> echo foobar > secretfile > But it does stay at chmod 600 if he does (append instead of truncate): > N:\> echo foobar >> secretfile > The "create mask" parameter is set to 644. I do not think this-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba