Re: [Samba] Switching between (status update)
Steve Tice stic6021 at gmail.com writes: I look forward to testing the proposal above and reporting back here with results. Motivated by a desire to stay employed, I have now accomplished what I set out to do. Using the tdb API, reading records from file_ntacls.tdb was a bit easier than expected. Using the setxattr system call, writing an ACL to an extended attribute, such that the acl_xattr module correctly reads the ACEs, was much easier than expected. I was able to copy the ACL data from the TDB to the EA with no translation or reformatting. To get started, I used source3/utils/smbcacls.c as a template utility program. I studied the tdb API. For guidance on how to open and read file_ntacls.tdb, I studied source3/modules/vfs_acl_tdb.c and source3/modules/vfs_acl_common.c. For guidance on how to write an ACL to an extended attribute, I studied source3/modules/vfs_acl_xattr.c. I'm still testing, but it's looking good. Thanks to everybody for patiently answering my questions and offering help. stic -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Switching between acl_tdb and acl_xattr
Andrew Bartlett abartlet at samba.org writes: Using Samba 4.0.0, the python bindings or even samba-tool ntacl get/set would be quite a good choice here. We can read directly the NT ACL from the tdb and then set it using the xattr code. I'm very happy to help out if you have any more questions here, as we certainly do have a good range of tools that should be able to help you out. Andrew, here's a status update on my attempts to accomplish this. 1. Attempted to build the source4 tree provided with the source tarball for the samba-3.5.10-125.el6 package. The build did not complete, failing when it tried to link bin/wbinfo. The pertinent output from make was Linking bin/wbinfo bin/mergedobj/cli_auth.o: In function `netlogon_creds_copy': (.text+0x17e3): undefined reference to `dom_sid_dup' collect2: ld returned 1 exit status make: *** [bin/wbinfo] Error 1 2. Successfully built (everything) from a samba-4.0.0beta8 tarball. Would you expect the source4 tree from the samba-3.5.10-125.el6 tarball to build without error? If it did build cleanly, would it even include the tools you mentioned above? Is it reasonable to continue on this path with samba-4.0.0beta8? Thanks, stic -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Switching between
Andrew Bartlett abartlet at samba.org writes: Using Samba 4.0.0, the python bindings or even samba-tool ntacl get/set would be quite a good choice here. We can read directly the NT ACL from the tdb and then set it using the xattr code. Wow - assuming the extended attributes produced by the Samba4 code are compatible with the Samba3 version we're using, that's a big short cut compared to what I had in mind. Thank you! I look forward to testing the proposal above and reporting back here with results. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Switching between
My organization is in the position of having to support full Windows ACLs on CIFS shares. We've been successfully utilizing Samba 3.5.10-125 and vfs_acl_tdb to accomplish that. However, the size of the resulting /var/lib/samba/state/file_ntacls.tdb[.unique-extension] file(s) has introduced some new problems for me to solve. In our environment, it seems on average each stored ACL causes file_ntacls.tdb to grow by almost 1000 bytes. That's what I've observed with my customers - YMMV. We have to support millions of files per server, and we've seen TDB files larger than 2 GB. Is there any server change I can make to reduce the storage demands of the acl_tdb module? Separately, we're considering switching from the acl_tdb module to the acl_xattr module. Do you know of any way to migrate or transfer the NTFS ACL data for each file from the TDB to an extended attribute? I'm trying to find a server-side solution to the migration problem. A client-side solution might be to rewrite each file (and resend the ACL data) after switching the Samba server configuration, but that puts a lot on the customers. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Switching between
That Subject line should read Switching between vfs_acl_tdb and vfs_acl_attr I'm guessing double quotes are a no-no in the Subject field. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Switching between
Jeremy Allison jra at samba.org writes: There's no code in Samba to do this unless you're doing it via a client. You could write custom code to pull the data out of the tdb and re-store as EA's on the files, but that's outside the scope of the tools we provide. Jeremy. Thanks Jeremy for confirming what I expected. I imagine the best documentation for writing such a migration would be the source for the VFS modules. Are there any other places to look for such info? For example, something that shows how to fetch a record from a TDB, and something that shows how to store ACL data in an EA. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Switching between
Jeremy Allison jra at samba.org writes: No, this is all in the source code and that's where you'll have to look I'm afraid. The tdb library documentation will tell you how to fetch the tdb records - the tdb key will be hashed device/inode number. Jeremy. Thanks again Jeremy. I'm sure the source files will be adequate. Had to ask if anything else (that might help get it done faster) existed, but it's all good. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] [solved] SMB2 CREATE + ACCESS_SYSTEM_SECURITY
On Tue, Dec 18, 2012 at 12:24:04PM -0600, Steve Tice wrote: Can anybody provide the expected response to an SMB2 CREATE request that includes ACCESS_SYSTEM_SECURITY in the DesiredAccess mask? I’m particularly interested in cases where the SMB client is connected as an authenticated user with administrative (superuser) privileges on the share, and has made the request on a directory. Should such a client expect full (read/change) access to the SACL (under any conditions)? The question above is theoretical in nature. Practically speaking, does any version of the Samba server respond correctly to the request described above? I have a Windows application that makes such a request, and have tested it against Samba server versions 3.5.10-125.el6 and 3.6.7. I keep seeing a response of NT_STATUS_PRIVILEGE_NOT_HELD, and think that's not the correct response when the client has superuser privileges - but perhaps my expectation is wrong. If I make the same request while connected to a share on a Windows server, the response is NT_STATUS_OK. Is there a Samba server configuration change I could make that would affect the behavior? Is there any setup work to do prior to sending the SMB2 CREATE request (for example, adding a privilege)? With all humility, please accept my apology for making a false claim on this topic. In my test bed, another factor (specifically a FUSE implementation) was found to be the root cause of the unexpected server behavior. With the root cause now corrected, my test bed with Samba 3.5.10-125.el6 is behaving as expected and is passing the previously posted test case. To summarize, there is no Samba bug associated with clients that want SYSTEM_SECURITY access to a share. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] SMB2 CREATE + ACCESS_SYSTEM_SECURITY
Jeremy Allison jra at samba.org writes:
On Tue, Dec 18, 2012 at 12:24:04PM -0600, Steve Tice wrote:
Can anybody provide the expected response to an SMB2 CREATE request that
includes ACCESS_SYSTEM_SECURITY in the DesiredAccess mask? I’m particularly
interested in cases where the SMB client is connected as an authenticated
user with administrative (superuser) privileges on the share, and has made
the request on a directory. Should such a client expect full (read/change)
access to the SACL (under any conditions)?
The question above is theoretical in nature. Practically speaking, does any
version of the Samba server respond correctly to the request described
above? I have a Windows application that makes such a request, and have
tested it against Samba server versions 3.5.10-125.el6 and 3.6.7. I keep
seeing a response of NT_STATUS_PRIVILEGE_NOT_HELD, and think that's not the
correct response when the client has superuser privileges - but perhaps my
expectation is wrong. If I make the same request while connected to a share
on a Windows server, the response is NT_STATUS_OK.
Is there a Samba server configuration change I could make that would affect
the behavior? Is there any setup work to do prior to sending the SMB2
CREATE request (for example, adding a privilege)?
You need to give the connected user the SeSecurity privilege.
Jeremy
Agreed. The Windows app which reproduces the behavior described above adds the
following privileges after creating but before attempting to open the new
directory:
SeSecurityPrivilege
SeBackupPrivilege
SeRestorePrivilege
I just noticed that my description above is incorrect. The unexpected behavior
occurs when attempting to open (not create) a directory. Here's a copy of the
Windows application source:
--
// Reproduce-Problem.cpp : Attempt to open a directory with
ACCESS_SYSTEM_SECURITY
// set in the dwDesiredAccess argument.
//
#include stdafx.h
#include windows.h
static void Usage(_TCHAR *progName)
{
wprintf(LUsage: %s DirectoryToCreate\n, progName);
}
static void ReportError(char *msg)
{
DWORD le = GetLastError();
printf(***ERROR*** %s; error code: %d\n, msg, le);
}
static BOOL CloseProcessToken(HANDLE pt)
{
BOOL ptClosed = CloseHandle(pt);
if (FALSE == ptClosed) {
printf( Unable to CloseHandle on ProcessToken.\n);
}
return ptClosed;
}
static void PrintCurrentPrivileges(void)
{
printf(Attempting to print current privileges...\n);
HANDLE pt;
BOOL ptOpened = OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, pt);
if (FALSE == ptOpened) {
ReportError( Unable to OpenProcessToken.);
return;
}
DWORD rl;
TOKEN_PRIVILEGES tokenInfo[32];
BOOL tokenInfoFetched = GetTokenInformation(pt, TokenPrivileges,
tokenInfo, sizeof(tokenInfo), rl);
if (FALSE == tokenInfoFetched) {
ReportError( Unable to GetTokenInformation.);
printf( sizeof(tokenInfo): %u; required: %u\n,
sizeof(tokenInfo), rl);
CloseProcessToken(pt);
return;
}
for (unsigned int i = 0; i tokenInfo[0].PrivilegeCount; ++i) {
TCHAR privName[256];
DWORD pnSize = 256;
BOOL lookedUp = LookupPrivilegeName((LPCWSTR) NULL,
tokenInfo[0].Privileges[i].Luid, privName, pnSize);
if (FALSE == lookedUp) {
ReportError( Unable to LookupPrivilegeName.);
printf( sizeof(privName): %u; required: %u\n,
sizeof(privName), pnSize);
CloseProcessToken(pt);
return;
}
wprintf(LPrivilege %u: LUID = %s, Attributes = 0x%X\n, i,
privName, tokenInfo[0].Privileges[i].Attributes);
}
CloseProcessToken(pt);
printf(All current privileges have been printed.\n);
}
static BOOL AddPrivilege(const wchar_t *privilege)
{
HANDLE pt;
BOOL ptOpened = OpenProcessToken(GetCurrentProcess(),
TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, pt);
if (FALSE == ptOpened) {
printf( Unable to OpenProcessToken.\n);
return FALSE;
}
LUID luid;
BOOL lookedUp = LookupPrivilegeValue((LPCWSTR) NULL, privilege, luid);
if (FALSE == lookedUp) {
printf( Unable to LookupPrivilegeValue.\n);
CloseProcessToken(pt);
return FALSE;
}
TOKEN_PRIVILEGES tp;
tp.PrivilegeCount = 1;
tp.Privileges[0].Luid = luid;
tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
BOOL privAdjusted = AdjustTokenPrivileges(pt, FALSE, tp,
sizeof(TOKEN_PRIVILEGES), (PTOKEN_PRIVILEGES) NULL, (PDWORD) NULL);
if (FALSE == privAdjusted) {
printf( Unable to AdjustTokenPrivileges.\n
[Samba] SMB2 CREATE + ACCESS_SYSTEM_SECURITY
Can anybody provide the expected response to an SMB2 CREATE request that includes ACCESS_SYSTEM_SECURITY in the DesiredAccess mask? I’m particularly interested in cases where the SMB client is connected as an authenticated user with administrative (superuser) privileges on the share, and has made the request on a directory. Should such a client expect full (read/change) access to the SACL (under any conditions)? The question above is theoretical in nature. Practically speaking, does any version of the Samba server respond correctly to the request described above? I have a Windows application that makes such a request, and have tested it against Samba server versions 3.5.10-125.el6 and 3.6.7. I keep seeing a response of NT_STATUS_PRIVILEGE_NOT_HELD, and think that's not the correct response when the client has superuser privileges - but perhaps my expectation is wrong. If I make the same request while connected to a share on a Windows server, the response is NT_STATUS_OK. Is there a Samba server configuration change I could make that would affect the behavior? Is there any setup work to do prior to sending the SMB2 CREATE request (for example, adding a privilege)? Thanks, Steve Tice stic6...@gmail.com stic6...@yahoo.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] SMB2 CREATE + ACCESS_SYSTEM_SECURITY
Can anybody provide the expected response to an SMB2 CREATE request that includes ACCESS_SYSTEM_SECURITY in the DesiredAccess mask? I’m particularly interested in cases where the SMB client is connected as an authenticated user with administrative (superuser) privileges on the share, and has made the request on a directory. Should such a client expect full (read/change) access to the SACL (under any conditions)? The question above is theoretical in nature. Practically speaking, does any version of the Samba server respond correctly to the request described above? I have a Windows application that makes such a request, and have tested it against Samba server versions 3.5.10-125.el6 and 3.6.7. I keep seeing a response of NT_STATUS_PRIVILEGE_NOT_HELD, and think that's not the correct response when the client has superuser privileges - but perhaps my expectation is wrong. If I make the same request while connected to a share on a Windows server, the response is NT_STATUS_OK. Is there a Samba server configuration change I could make that would affect the behavior? Is there any setup work to do prior to sending the SMB2 CREATE request (for example, adding a privilege)? Thanks, Steve ticestic6...@gmail.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Connected client unaffected by group/user/share change
On Fri, Mar 30, 2012 at 5:25 PM, Chris Weisswrote: the quick and dirty hack is to use smbstatus to get the clients PID and kill it. Yes, that's the sort of active revokation I'm looking for. Thanks for the suggestion. More difficult is the art of detecting that a connection should be torn down (because the connected user should no longer have access). For each existing connection, perhaps I'd need to see if a new connection with all the same parameters can currently be established. In a perfect world, I could test authorization and validity of the new connection without requiring the user's password. In other words, it would be helpful to test authorization without first having to authenticate. Is such a test possible? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Connected client unaffected by group/user/share change
I am trying to solve what I perceive as undesirable behavior of my Samba server. Please understand I am not claiming this is a bug in Samba. It is simply different from the behavior I want, and I'm asking for help in modifying the behavior. My Samba server is version 3.5.4 (release 68.el6) and runs under CentOS 6.0 (x86_64). I happen to use Active Directory (AD) to authenticate, but am not convinced this behavior is specific to AD. What follows is a generalized statement of the undesirable behavior, with the context provided first as a sequence of events: 1) A CIFS client establishes (and maintains) a connection to a CIFS share on our Samba server. Everything is normal so far. 2) After that connection has been established, a configuration change is made (examples provided as bullets below) which I think should immediately revoke the CIFS client's access to the connected CIFS share. For example: o Active Directory user is deleted from the domain (via the Active Directory Administrative Center on the domain controller). o The Active Directory user is removed from the CIFS share's list of permitted users (on the Samba server host). o The CIFS share is deleted (on the Samba server host). Here’s the undesirable behavior. As long as the CIFS client maintains the existing connection to the CIFS share, access to that share is not revoked. That is, the user continues to have the same access to the share as they did when the connection was first established. The desired behavior is for access to be revoked as soon as the configuration change pertinent to access rights is finalized. Disconnecting the affected client session(s) is acceptable and appropriate, but disconnecting other sessions (unaffected by the configuration change) is undesirable. I would like to get your ideas toward an approach, programmatic or otherwise, that will yield the desired behavior. Perhaps this is as simple as changing my Samba server’s configuration; I have not found any configuration parameters that appear relevant to this behavior. Thanks for reading. Sincerely, Steve Tice -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
