Just one idea (not tested):
>From ¨IBM Tivoli Storage Manager: Building a Secure Environment" -
http://www.redbooks.ibm.com/abstracts/sg247505.html?Open [personal marketing
here :) ]
On page 46 we have a script to collect current permissions from a tree of
directory and its files.
[EMAIL PROTECTED]:/usr/tivoli/tsm # find <dir> -ls | awk '{printf "%s %s %s
%s\n",
$3, $5, $6, $11}' > orig_permissions.txt
You could cron this command as a script to run daily and backup the output
file together with your regular files. When you need a point in time
restore, you bring the specific file from that day also, and reapply the
permissions and owners with the following steps (page 47):
Generate a script to revert the ownership of the files and directories,
issuing the
command:
[EMAIL PROTECTED]:/usr/tivoli/tsm # cat orig_permissions.txt | awk '{ printf
"chown
%s:%s %s\n",$2,$3,$4 }' > recover_owner.sh
[EMAIL PROTECTED]:/usr/tivoli/tsm # chmod 500 recover_owner.sh
Generate a script to recover the original permission settings of the files:
[EMAIL PROTECTED]:/usr/tivoli/tsm # cat orig_permissions.txt | sed
"s/^\([-d]\)\([-rwx][-rwx][-rwx]\)\([-rwx][-rwx][-rwx]\)\([-rwx][-rwx][-rwx]\)/
u=\2,g=\3,o=\4/;s/\([=rw]\)-*/\1/g" | awk '{ printf "chmod %s %s\n",$1,$4 }'
>
recover_perm.sh
[EMAIL PROTECTED]:/usr/tivoli/tsm # chmod 500 recover_perm.sh
Execute the scripts:
[EMAIL PROTECTED]:/usr/tivoli/tsm # ./recover_owner.sh
[EMAIL PROTECTED]:/usr/tivoli/tsm # ./recover_perm.sh
On Dec 12, 2007 1:53 PM, Dave Mussulman <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 11, 2007 at 09:43:29AM -0600, Shawn Drew wrote:
> > I'm trying to figure out when the permission of certain files changed.
> I
> > ran a few tests, and I'm not sure I like the behavior of TSM. Maybe I'm
> > missing something.
> >
> > - I backed up a file a month ago.
> > - The file hasn't changed for a month
> > - Today I changed the permission from 644 to 444.
> > - I ran a "dsmc i" and it didn't back up the file again, just updated:
> > "Total number of objects updated: 1"
> > - When I browse the files for restore, there was no indication of the
> > permission change
> > - When I restore the file with a point-in-time from before this update,
> it
> > still restores the file with the current permission!
> >
> > It doesn't seem this is how it should work, but I do understand that the
> > metadata of the file is probably stored in the TSM DB and there is
> > probably no facility to maintain metadata history. Does this seem
> > strange to anyone?
>
> Hi Shawn,
>
> AFAIK, TSM doesn't keep a back history of unix file permissions. It's
> one of those "gotcha" cases where point-in-time restores from inactive
> versions aren't actually point-in-time (because they'll use whatever the
> active file's permissions are.) It does seem strange.
>
> It's also not consistent with different file types. NTFS permissions
> are stored with the file, and so you'll see an active/inactive increment
> when permissions are changed. The QuickFacts explains it as "this is
> warranted as the attributes are vital to the files." I'm not sure why
> that's true for Windows and not Unix. (Other than the fact my Unix
> admins would probably figure it out and be able to move on if they had
> to do a restore and then adjust permissions. My Windows admins would
> make a much bigger fuss about recreating that permissions structure.)
>
> I'm not sure how other file/attribute combinations are handled (zfs,
> ext2/3 extended attributes, ufs, macos) but it would be nice if that was
> consistent and/or documented somewhere. At first blush, I'd at least
> want that information backed up (I'm not sure ext2 extended attributes
> are backed up at all) and, it would be great they were versioned with
> the files.
>
> Dave
>
--
Helder Garcia
