It is true that these rights will skip ACL checking. However
the application (the AV guys) need to enable the privileges
if the account was granted them ("granted" != "enabled").
Backup programs explicitly enable these rights.
--
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
"Tom Rodman" <Use-Author-Address-Header@[127.1]> wrote in message
news:(E-Mail Removed)...
> Mark - thanks for your perspective on this. I see things
> differently though; IMHO backup software has no conflict.
> The account running the backup process may be denied
> rights to an object through an ACL (or for example perhaps
> *only* the end username appears in the ACL) *yet* the backup
> process reads every byte associated with that object and writes
> it to tape. You have to be able to backup all files right, you
> can not allow users to prevent their own work from being backed
> up!
>
> I always thought that the crucial backup related
> rights were:
>
> "backup files and directories"
> "restore files and directories"
>
> I would assume that the account running the AV process would be
> granted the above rights- empirically, I don't think that is
> a solution though.. (pls correct me if it's that simple)
>
> Why can't anti-virus software take advantage of
> the same OS facility that backup software uses?
>
> Pls let me know what I'm missing..
>
> --
> thanks again/regards,
> Tom Rodman
> pls run for my address:
> perl -e 'print unpack("u", "\.\=\$\!T\<F\]D\;6\%N\+F\-O\;0H\`");'
>
> "Mark Zbikowski \(MSFT\)" <(E-Mail Removed)> wrote:
> >Well... AV products need to examine data. ACL's are used to protect
data.
> >
> >There's a fundamental conflict here.
> >
> >My only suggestion would be to run the AV software from an account
> >in the Administrators group. This is not a complete solution (there
aren't
> >any) since an ACL may explicitly DENY access to any arbitrary user.
> >
> >--
> >Disclaimer: This posting is provided "AS IS" with no warranties, and
confers
> >no rights.
> >
> >"Tom Rodman" <Use-Author-Address-Header@[127.1]> wrote in message
> >news:(E-Mail Removed)...
> >> Our norton anti-virus software is unable to thoroughly scan our
> >> server's disks - apparently due to permissions. We require a
> >> fix that does *not* involve changing file permissions or ACLs.
> >> Were running "Norton AntiVirus Corporate Edition" v7.6 on
> >> windows 2000 server. Can any one help?
> >>
> >> Example errors in application event log:
> >>
> >> 030406 00:00:20 Norton AntiVirus Warning None 6 NA C7MKES109 Scan
> >could not
> >> open file C:\aut\cyg\etc\ssh_host_dsa_key [00000003]
> >> <snipped>
> >> 030406 00:12:54 Norton AntiVirus Warning None 6 NA C7MKES109 Scan
> >could not
> >> open file D:\Database_Pack_Files\production.cpk [00000003]
> >>
> >> --
> >> thanks/regards,
> >> Tom Rodman
> >> pls run for my address:
> >> perl -e 'print unpack("u", "\.\=\$\!T\<F\]D\;6\%N\+F\-O\;0H\`");'
> >>
> >> # ====================================================================
> >> # why we do not want to restrict the permissions our end
> >> # users assign to their own objects:
> >> # ====================================================================
> >>
> >> o eventually there will be users that violate the rules, and or
insist
> >> that they be allowed to do so. This can get
> >> political - you can not / will not always win political skirmishes.
> >> System admins are not always treated like gods by management.
> >>
> >> o IMHO users may have a valid reason for *not* granting the
> >administrators
> >> access to an object. Why should they be forced to? Our users are
sof
> >tware
> >> developers, perhaps they need to have very strict permissions for
code
> >test
> >> cases. End users deserve respect, they pay for us with their work.
> >>
> >> o This attitude that user's should not be able to permissions to
objects
> >> they own to what ever they want is IMHO arrogant, arrogant
consistent
> >> with the worst of "Microsoft culture". In contrast UNIX has no
such
> >> constraints - tools exist for "root" to backup all objects to a
> >non-tape
> >> archive regardless of their permissions or acls.
> >>
> >> o I can give you a specific example where a production database
requires
> >a
> >> all objects below a given directory have an explicit ACL value
> >> that does *not* include system or administrators. If an object is
> >> changed to include either of the above groups, then the application
> >> will not work- at some point it will self repair by resetting all
> >> the permissions on the tree so that these groups are removed.
> >>
> >> o another example is cygwin's ssh client, for each ssh end user,
their
> >> $HOME/.ssh/ dir should be set for access *only* by the user, no
> >access - not
> >> even read or execute to anyone else. I may not be entirely correct
> >> on this one, but I know the permissions on ~/.ssh/ are quite strict
> >> by design (it's a "secure shell" after all).
> >>
> >> o NTFS has an incredibly rich permissions capability - more so than
> >UNIX.
> >> To insist that administrators or system have full control to every
> >object
> >> "dumbs down" this richness and seems to contradict it's design.
> >>
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
Similar Threads
