ADSM-L

Re: [ADSM-L] Tracking Permission Changes

2007-12-12 13:57:31
Subject: Re: [ADSM-L] Tracking Permission Changes
From: Helder Garcia <helder.garcia AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 12 Dec 2007 15:05:38 -0200
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.

root@myhost:/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:
root@myhost:/usr/tivoli/tsm # cat orig_permissions.txt | awk '{ printf
"chown
%s:%s %s\n",$2,$3,$4 }' > recover_owner.sh
root@myhost:/usr/tivoli/tsm # chmod 500 recover_owner.sh

Generate a script to recover the original permission settings of the files:
root@myhost:/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
root@myhost:/usr/tivoli/tsm # chmod 500 recover_perm.sh

Execute the scripts:
root@myhost:/usr/tivoli/tsm # ./recover_owner.sh
root@myhost:/usr/tivoli/tsm # ./recover_perm.sh



On Dec 12, 2007 1:53 PM, Dave Mussulman <mussulma AT uiuc DOT edu> 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