|
The user can still delete the file if the "Delete Subfolders and Files" permission is granted to, or inherited from, some parent folder of the file.
|
|
|
|
|
I experimented with setting the enclosing Folder's delete permission to 'deny, as well as the file in that folder: can still delete it from the desktop in the standard way.
I am running a User account that has 'Admin privileges.
thanks, Bill
«If you search in Google for 'no-one ever got fired for buying IBM:' the top-hit is the Wikipedia article on 'Fear, uncertainty and doubt'» What does that tell you about sanity in these times?
modified 28-Nov-14 22:05pm.
|
|
|
|
|
Hi Bill,
after some experiments and lots of hair pulling I've come to the following conclusion and result that works on Windows 7 (I Work for a company that does most certainly not fit the description "early adaptor".)
In a nutshell:
If and only if both the "FILE_DELETE_CHILD" access right on the files parent folder and the "DELETE" right on the file itself are set to "DENY" can the file not be deleted even after the system has requested elevated rights. This presumes that the user is logged on with an account that is a member of the group local Administrators and the previously mentioned denials of rights were applied to that group.
This is pretty much it. I was a bit stumped that denial of the "FILE_DELETE_CHILD" right on the containing folder did not suffice to hinder the deletion. I did not try it with a normal account though.
Regards,
Manfred
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Here is a program that I ran both with elevated rights (Run as Administrator) and without elevated rights. Either way it is impossible to delete the fileTwo.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.DirectoryServices;
using System.IO;
using System.Security.AccessControl;
using System.Security.Principal;
namespace AppPoolEnum
{
class Program
{
private static void Main(string[] args)
{
String filePath = @"D:\Temp\Manfred\Delete-3-Test";
String accountName = String.Format("Administrators");
if (!Directory.Exists(filePath))
Directory.CreateDirectory(filePath);
setNoDeleteChildren(filePath, accountName);
String fileOne = String.Format("{0}\\{1}", filePath, "File-One.txt");
String fileTwo = String.Format("{0}\\{1}", filePath, "File-Two.txt");
File.Create(fileOne).Dispose();
File.Create(fileTwo).Dispose();
if (File.Exists(fileOne) && File.Exists(fileTwo))
Console.WriteLine("Both files {0} and {1} exist!", fileOne, fileTwo);
setNoDeleteFile(fileTwo, accountName);
File.Delete(fileOne);
File.Delete(fileTwo);
}
private static void setNoDeleteFile(String path, String account)
{
FileSecurity security = File.GetAccessControl(path);
security.AddAccessRule(new FileSystemAccessRule(account, FileSystemRights.Delete, AccessControlType.Deny));
File.SetAccessControl(path, security);
}
private static void setNoDeleteChildren(String path, String account)
{
DirectorySecurity security = Directory.GetAccessControl(path);
security.AddAccessRule(new FileSystemAccessRule(account, FileSystemRights.DeleteSubdirectoriesAndFiles, AccessControlType.Deny));
Directory.SetAccessControl(path, security);
}
}
}
Regards,
Manfred
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Hi Manfred, thanks so much for taking the time to look into this. I am going to test your ideas later today.
This little adventure was "inspired" by a QA question from someone who wanted a FileSystemWatcher that would monitor file-deletes and instead of actually deleting the file move the file to a special folder. Of course, you get a FileSystemWatcher notification only after the event ... and no facility to cancel the event ... so I was playing with the idea that when the file is created it gets delete-denied, then when the attempt to delete is made I either get a notification of a 'delete or an file-error of some type, which I could trap: at that point I could move copy the file to the "deleted folder," and really delete the file in the folder being watched by the FileSystemWatcher.
cheers, Bill
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. » Alan Kay's clarification on what he meant by the term "Object" in "Object-Oriented Programming."
|
|
|
|
|
BillWoodruff wrote: instead of actually deleting the file move the file to a special folder.
Oh oh, that is one of the oddities I also discovered, but did not cover in my answer to your post: Moving a file as well as only renaming the file will not work when the account trying to accomplish that has been denied the delete right on said file.
I've googled about this "feature" quite a bit, but did not reach any hindsight as to what "special implementation"*1 would cause this kind of havoc. All that this confirms to me is that the windows authorization scheme seems to be utter BS.
Cheers!
*1And by special I mean this kind of "special": Special (Fr)ed, Stephen Lynch[^]
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
I guess last time I went to wild with my google foo.
This time with a more moderate approach I actually found this: Permissions for Renaming a File[^] and it actually explains what is going on behind the scenes: "Windows treats a file renaming operation as a deletion of the file and creation of a new file with the new name. ..." and goes on with an explanation of additional permissions that are needed in order to rename a file.
Regards,
Manfred
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Hi,
I would like to ask how can I write to LOCAL_MACHINE registry from my .NET application when the window user is limited user?
Can I write with Administrative Privileges?
Thanks,
Jassim
Technology News @ www.JassimRahma.com
|
|
|
|
|
You can only use administrator privileges if you are running under an administrator account. If you are running under an ordinary user account then you need an administrator account password to allow it.
|
|
|
|
|
No you can't. If you pause and think about it for a little while, you can see that it makes sense because you would end up exposing a large security hole if you could do things with your app that the user doesn't have the privileges to do.
|
|
|
|
|
but how can I make the changes by prompting the user to enter the administrator user id and password and if successful the use it to make the changes?
is this possible?
Technology News @ www.JassimRahma.com
|
|
|
|
|
Jassim Rahma wrote: is this possible? Possible yes, sensible no. What happens if the user is running in a non-administrator account and does not have access to the administrator password?
|
|
|
|
|
It won't be the case because the person who needs to change myst have the administrator password.
So how can i implement the administrator user id and password prompt?
Technology News @ www.JassimRahma.com
|
|
|
|
|
There is nothing to implement, Windows does it for you. But it is still a bad idea.
|
|
|
|
|
I ried but getting the following message:
Application attemped to perform an operation not allwoed by the security porlicy. To grant this application the required permission, contact your system administrator or use the Microsoft.NET Framework Configuration tool
Technology News @ www.JassimRahma.com
|
|
|
|
|
That seems quite clear, and even tells you who to talk to about it.
|
|
|
|
|
As you have been told, you can't do it without admin privileges.
But the bigger question remains: why are you writing to the registry?
It's a bad idea: access has been getting more and more restricted (and for good reason, it was heavily abused in the early days) and is not going to get any less restricted in future versions. More restrictions should be expected instead.
So why write there?
Why not use somewhere else - somewhere that you are allowed to write to: Where should I store my data?[^] may help.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
class Base
{
[Display(Order = 0)]
public int FirstProp {get;set;}
[Display(Order = 1)]
publuc string SecondProp {get; set;}
}
class Derived : Base
{
[Display(Order = 2)]
public string ThridProp {get;set;}
}
I was expecting that the properties will have an order like this
| FirstProp | SecondProp | ThirdProp |
But I was getting like this
| ThridProp | FirstProp | SecondProp |
What was i missed?
BTW i was binding it in a gridview.
I will appreciate for any help will come.
Thank you
|
|
|
|
|
I'm not familiar with the GridView, but the behaviour looks like its started with fields in the derived class before moving onto the base class. If that's the case, that's a pretty dumb implementation.
|
|
|
|
|
What is your suggestion?
Actually i am just using auto-implemented property and i am not using any fields.
|
|
|
|
|
Gilbert Consellado wrote: What was i missed? Make the properties virtual, override them in the derived class, add the attribute.
Yes, that's more work, but it is also more logical.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yeah you're right.
But in msdn documentation that DisplayAttribute.Order[^] can change the order of the properties. And i tried it but no success.
|
|
|
|
|
Gilbert Consellado wrote: But in msdn documentation that DisplayAttribute.Order[^] can change the order of the properties. You mean it does not work if you mirror the properties in the derived class?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|