API's to get File Owner

[OldxBaser]

In a VFP program, I am trying to get the file owner using the following APIs:
GetFileSecurity
GetSecurityDescriptorOwner and
LookupAccountSid.

If I run the application on my C: drive, I get Administrator as owner.
If I run it on the network, i get an empty string.
If I copy or move a file using the application, I get right away as owner the person running the application, but after I refresh the folder, the owner goes back to empty string.

The APIs documentation states that :

The information obtained is constrained by the caller's access rights and privileges.

To read the security descriptor of a file or directory, the calling process must have READ_CONTROL access or be the owner of the file or directory.

Can you tell me what exactly this means, and maybe give me an example?

Thanks

 

[DSummZZZ]

It sounds like you're making the call correctly or you wouldn't be getting results back from reading the file from your hard drive.
It doesn't sound like you have sufficient rights on the network to read the security descriptor on the network volume though. Merely copying it, you would probably already have your local security descriptor cached. But when it comes time to read it from the network again, your network rights would come in to play.
Does that make sense?


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[OldxBaser]

Thanks Dave ...
If the program runs on the network but the files are on my local drive, I get the owner. But if the files are on the network, don't get the owner. Is there a generic way around this rights issue?

Roy

 

[Olaf Doschke]

Pardon me, for jumping in,

>If the program runs on the network
I doubt that.

If you put an EXE on the network and users start it, it runs on their local CPU, it doesn't run on the network PC. It doesn't matter if the shortcut you start or the EXE you double click is local or in the network, it's loaded into local RAM and CPU.

So your situation merely depends on the location of the files you want to inspect. Your third case seems weird, because if your application generates a file in the netwrk, the current user automatically is the file owner. Is it a peer to peer network (Workgroup) or a domain? FAT or NTFS file system? If you copy a file, access privileges are copied, too, but the directory to which you copy can have options set to let files inherit it's privileges, no matter if generated there or copied there, so you should perhaps look into parent folder security settings.

Bye, Olaf.

 

[jimoo]

Take it out of fox just for a momement to see if it is your environment.

Here is a sample using the windows scripting host. Create a directory and put just a few files inside it. Modify the code to point to this directory. Saved code below with a .vbs extension and double click it to execute it. This will show multiple attributes. If this works you know you can pick up the user name. You could then continue debugging (knowing you have permissions) or even modify the fox code to call the scripting host.

Note: I named my directory C:\$wipe and placed a few files inside it.

Set objShell = CreateObject ("Shell.Application")
Set objFolder = objShell.Namespace ("C:\$wipe")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Dim arrHeaders(13)
For i = 0 to 13
arrHeaders(i) = objFolder.GetDetailsOf (objFolder.Items, i)
Next
For Each strFileName in objFolder.Items
For i = 0 to 13
If i <> 9 then
Wscript.echo arrHeaders(i) _
& ": " & objFolder.GetDetailsOf (strFileName, i)
End If
Next
Wscript.Echo
Next


Jim

 

[OldxBaser]

Thanks Olaf ... will check that out ...
Thanks Jim ... will try that and let you know what I find ...
Roy

 

[OldxBaser]

Olaf,
What kind of rights or security settings should be granted to actually get the file owner?
Basically, the VFP EXE is run from a network drive, and all the shared DBFs reside on that drive.
One of the forms allows selection of a client to see all client accounting details.
The users have the ability to copy a document to the network drive and have a link to that document from a grid associated with the specific client file. Any users can see the list of 'attached' documents and see the owner of each document. Some documents don't show the owner.
thanks

 

[Olaf Doschke]

Please reread,

actually I already said what you need to know. You don't need to know the owner of files, you need to solve your higher level problem: App users write files to network folders and all of them should be able to read these docs, right?

Quoted from

https://www.idp.net/NTFS/

https://www.idp.net/NTFS/[/URL]]Try not to assign any NTFS permissions at the file level. This increases the complexity of managing the permissions. Assign the NTFS permissions at the folder level only. If several files require the same access, move them to a common folder and assign the permissions to that folder.

I understand you don't set file owner, you simply copy files. That's fine and can stay that way.

Just once, only one time, manually create a folder where you store your documents, and set permission on that FOLDER level to
"Replace all existing inheritable auditing entries on all descendants with inheritable auditing entries from this object"

Done. For all current and future files in that folder.

That's an option you find in advanced properties of the security tab of the folder, in it's permission tab, in the dialog appearing if you click on change permissions (the button with the UAC shield symbol).

Of course you then give sufficient permissions to read files to the usergroup, of which all your application users are members.

Bye, Olaf.

PS: The other option, to give your users enough permissions to see the file owner of network files, would give them too much privileges in the network, you won't want that.