ADSM-L

Re: [ADSM-L] Tracking Permission Changes

2007-12-12 12:41:14
Subject: Re: [ADSM-L] Tracking Permission Changes
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 12 Dec 2007 11:49:59 -0500
That's odd, so if you get hit with some virus that messes up all your
permissions, you are out of luck?  Or worse, a junior CHMOD admin?!
-Shawn

________________________________________________
Shawn Drew
Data Protection Engineer
Core IT Production
BNP Paribas RCC, Inc.





Internet
mussulma AT UIUC DOT EDU

Sent by: ADSM-L AT VM.MARIST DOT EDU
12/12/2007 10:53 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Tracking Permission Changes





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


This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.