{

System.Security.Principal.WindowsIdentity windowsIdentity = System.Security.Principal.WindowsIdentity.GetCurrent();

DirectorySecurity dSecurity = dInfo.GetAccessControl();

dSecurity.RemoveAccessRuleSpecific(new FileSystemAccessRule(windowsIdentity.User, FileSystemRights.FullControl, AccessControlType.Allow));

dInfo.SetAccessControl(dSecurity);

}

catch (Exception eX)    {MessageBox.Show(" error " + eX.Message);}

To θέμα είναι ότι η εφαρμογή θα πρέπει να έχει το δικαίωμα να μπορεί να αλλάζει τα δικαιώματα. Οι εφαρμογές τρέχουν κάτω από κάποιο user security context, δεν σημαίνει ότι επειδή απλά λες RemoveAccessRuleSpecific αυτό θα γίνει. Ειδικά για τον φάκελο Program Files δεν ξέρω αν ακόμα κι αν την τρέξεις (run as...) ως adminitrator ότι θα τα καταφέρει. Και αυτό είναι πολύ λογικό γιατί ο φάκελος Program Files είναι πολύ σημαντικός για να μπορεί να τον πειράζει οποιαδήποτε εφαρμογή. Εξάλλου, σκέψου ότι ακόμα και για να τρέξει ο installer και να εγκαταστήσει την εφαρμογή πρέπει να τρέξει από κάποιον χρήστη με δικαιώματα administrator.

Τώρα, αν θέλεις να βάλεις το αρχείο της Access κάπου που να μπορεί να χρησιμοποιηθεί από την εφαρμογή, θα πρέπει να μπει στους κατάλληλους φακέλους κι επειδή το path αλλάζει ανάλογα με το λειτουργικό, τον χρήστη, το αν είναι roaming το profile του, κλπ, καλύτερα να χρησιμοποιήσεις το object Application που δίνει την πρόσβαση στους κατάλληλους φακέλους:

• Application.CommonAppDataPath
• Application.LocalUserAppDataPath
• Application.UserAppDataPath

Ρίξε και μια ματιά στο MSDN http://msdn.microsoft.com/en-us/library/system.windows.forms.application.aspx

Ωχ, ωχ, ωχ και πάλι ωχ!!! Έπεσες θύμα του UAC (User Account Control). Από που ν' αρχίσει κανείς και που να τελειώσει. Ένα πράγμα μόνο είναι σίγουρο. ΜΗΝ ΤΟΝ ΑΠΕΝΕΡΓΟΠΟΙΗΣΕΙΣ!! Έχω δει πάρα πολλούς να το κάνουν και δεν αναφέρομαι σε χρήστες.

Κατ' αρχήν, ό,τι έχει σχέση με το directory 'Program Files' είναι OFF LIMITS. Ο Μάνος (Kelman) έχει δίκιο. Το πρώτο πράγμα που πρέπει να κάνεις είναι να διαβάσεις τι είναι το UAC και γιατί δημιουργήθηκε. Εδώ θα βρεις πληροφορίες για τα Win 7. Οι λόγοι για τους οποίους οι εφαρμογές δεν τρέχουν όπως παλιά είναι δύο: 1) Registry Virtualization και 2) File Virtualization. Εξαιτίας του δεύτερου, ακόμα και αν χρησιμοποιήσεις το CommonApplicationData directory, το οποίο βλέπει σε διαφορετικό physical path ανάμεσα στις εκδόσεις των Windows, πάλι θα έχεις πρόβλημα. Αν στην εφαρμογή σου δεν έχεις ενσωματώσει το κατάλληλο manifest file, παρόλο που η βάση δεδομένων θα είναι εγκατεστημένη σε κοινόχρηστο folder, για κάθε χρήστη θα δημιουργηθεί το αντίστοιχο virtual file και κανείς δεν θα έχει πρόσβαση στα κοινά δεδομένα, παρά μόνο στα δικά του. Βέβαια, αν αναφέρεσαι σε συγκεκριμένο χρήστη κάθε φορά (ApplicationData, LocalApplicationData) δεν θα συναντήσεις τέτοιο πρόβλημα.

Για να γράψεις σε κοινόχρηστο directory, έτσι κι αλλιώς η εφαρμογή σου θα πρέπει να τρέχει με elevated privileges (administrator). Αυτό το δηλώνεις στο manifest file. Αν δουλεύεις σε Visual Studio 2005, η ενσωμάτωσή του σε managed εφαρμογές μπορεί να χαρακτηριστεί επιεικώς σαδιστική. Το πως το επιτυγχάνεις περιγράφεται σ' αυτό το video, αλλά και εδώ. Αν παίζεις με Visual Studio 2008, απλά πρόσθεσε ένα manifest file στην εφαρμογή σου, με τον ίδιο τρόπο που προσθέτεις μια φόρμα ή μια κλάση. Πολύ χρήσιμες πηγές (MUST) αποτελούν και τα εξής άρθρα:

1) Vista UAC: The definite guide

2) Certification by example

3) Common application data, virtualization, and access control lists (ACL)

Επίσης, καλόν είναι οι εφαρμογές σε Vista και Win7 να είναι signed (μη στενοχωριέσαι, ούτε οι δικές μου είναι). Καλό διάβασμα και οπλίσου με υπομονή. Δυστυχώς, πρόκειται για το λιγότερο τεκμηριωμένο κομμάτι για εφαρμογές σε Windows. Εγώ, μάλιστα, απορώ γιατί οι ερωτήσεις που αφορούν στο UAC είναι τόσο λίγες στο forum. Δυστυχώς, δε μπορώ να σε βοηθήσω περισσότερο. Αν κάποιος έχει να προσθέσει κάτι ας το κάνει γιατί θεωρώ ότι υπάρχει "έλλειμμα" άρθρων.

Τον μεγάλο πανικό τον προκάλεσε το virtualization. Δεν ξέρω για σας, αλλά εμένα προσωπικά μου πήρε αρκετό χρόνο να συμμαζέψω τις πηγές και να βάλω τα πράγματα σε μια σειρά. Τα περισσότερα fora πάνω σ' αυτό θέμα λειτουργούν περισσότερο σα γραμμή παραπόνων, ακόμη και σήμερα. Έχουν και κάποιο δίκιο βέβαια. Τι εξυπηρετεί το virtualization σε directory που δημιουργήθηκε για κοινόχρηστη πρόσβαση δεδομένων; Επίσης, τα δικαιώματα πρόσβασης πρέπει να τα καθορίσεις κατά το installation της εφαρμογής. Πάντως, στο θέμα του UAC, ακόμα αισθάνομαι σαν το ψάρι έξω από το νερό, με τα Vista ήδη ν' αποτελούν παρελθόν...

Markos:

Τον μεγάλο πανικό τον προκάλεσε το virtualization. ... Τι εξυπηρετεί το virtualization σε directory που δημιουργήθηκε για κοινόχρηστη πρόσβαση δεδομένων; ...

Το ωραίο είναι ότι μπορείς να απαντήσεις πλήρως σε αυτή την ερώτηση με ελάχιστες λέξεις:

• Ασφάλεια
• Σταθερότητα
• Συμβατότητα

Το κακό είναι γιατί ενώ η τεχνολογία του virtualization υπάρχει από τα Windows XP SP2 τους πήρε τόσα χρόνια να φτάσουμε στo UAC που ξέρουμε σήμερα...

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Χμ... Η ερώτηση δεν είναι δικιά μου. Την έχω συναντήσει σε forum. Θεωρώ ότι έχει κάποια βάση τη στιγμή που πρόκειται για folder κοινής πρόσβασης. Αλλά το όποιο πλεονέκτημα σε ασφάλεια δεν αναιρείται κατά κάποιον τρόπο τη στιγμή που για να γράψεις σ' αυτό, το requestExecutionLevel της εφαρμογής πρέπει να γίνει requireAdministrator; Πολλά από τα θέματα του UAC αφορούν στο deployment των εφαρμογών και θα έπρεπε να είναι περισσότερο τεκμηριωμένα, μιας και τα πιθανά σενάρια είναι πάρα πολλά. Άλλωστε, το έγραψα και πιο πάνω: ΜΗΝ ΑΠΕΝΕΡΓΟΠΟΙΕΙΤΕ ΤΟ UAC!!! Ένα άλλο ερώτημα που έχω είναι, αν ενσωματώσω στο manifet του exe αυτό το επίπεδο execution, χρειάζεται να το δηλώσω και σε manifest στα custom dlls που γίνονται referenced σ' αυτό ή τα δικαιώματά του αναβαθμίζονται αυτόματα επειδή τα καλεί εκτελέσιμο με δικαιώματα administrator; Όπως και να το δει κανείς, υπάρχουν απορίες...