Attacking Potential of sh-scripts Post: 302508492

Sponsored Content

Special Forums Cybersecurity Attacking Potential of sh-scripts Post 302508492 by joeyg on Monday 28th of March 2011 09:49:46 AM

03-28-2011

Registered User

Theoretically speaking, I believe the greater danger (than deleting data) is the random alteration of data. For instance, if I discovered that I was missing data for 100 people, I could restore a backup copy to determine the missing records and then copy the missing individuals back into a database.
However, something that randomly changed a field in random records would be more difficult to recover. How would I know what data was changed correctly by a user vs. a 'bad script'.

This User Gave Thanks to joeyg For This Post:

joeyg

View Public Profile for joeyg

Find all posts by joeyg

3 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Potential new user of Unix

Hi all, Complete and utter virgin Unix person here (I don't even have the OS yet) As I'm doing a "looking into it" kinda thing before I move from MS I hope my questions are not inappropriate. 1. Should I get some kind off anti virus software. I know Unix is pretty good for not getting them...

2. AIX

how to handle potential file contention

I need to change how a posting procedure currently works in order to improve load balancing but I am hitting a potential file contention problem that I was wondering if someone here could assist me with... In a directory called FilePool I would have a bunch of files that are constantly coming in...

3. HP-UX

Potential file system contention on directory

We have an 8-processor Itanium system running HP-UX 11.23 connected to shared SAN discs. We have an application that creates files (about 10) in a specific directory. When the application terminates, these files are removed (unlink) and a few others are updated. The directory contains...

LEARN ABOUT OPENSOLARIS

vgcfgrestore

VGCFGRESTORE(8) 					      System Manager's Manual						   VGCFGRESTORE(8)

NAME

       vgcfgrestore - restore volume group descriptor area

SYNOPSIS

       vgcfgrestore [-d|--debug] [-f|--file filename] [-l[l]|--list] [-h|--help] [-M|--Metadatatype1|2] [-t|--test] [-v|--verbose] VolumeGroupName

DESCRIPTION

       vgcfgrestore  allows  you  to  restore  the metadata of VolumeGroupName from a text backup file produced by vgcfgbackup.  You can specify a
       backup file with --file.  If no backup file is specified, the most recent one is used.  Use --list for a list of the available  backup  and
       archive files of VolumeGroupName.

OPTIONS

       -l | --list -- List files pertaining to VolumeGroupName
	      List  metadata  backup  and  archive  files  pertaining  to VolumeGroupName.  May be used with the -f option.  Does not restore Vol-
	      umeGroupName.

       -f | --file filename -- Name of LVM metadata backup file
	      Specifies a metadata backup or archive file to be used for restoring VolumeGroupName.  Often this file has been created with  vgcfg-
	      backup.

       See lvm for common options.

REPLACING PHYSICAL VOLUMES

       vgdisplay  --partial  --verbose will show you the UUIDs and sizes of any PVs that are no longer present.  If a PV in the VG is lost and you
       wish to substitute another of the same size, use pvcreate --restorefile filename --uuid uuid (plus additional arguments as appropriate)	to
       initialise  it with the same UUID as the missing PV.  Repeat for all other missing PVs in the VG.  Then use vgcfgrestore --file filename to
       restore the volume group's metadata.

SEE ALSO

       lvm(8), vgcreate(8)

Sistina Software UK					 LVM TOOLS 2.02.95(2) (2012-03-06)					   VGCFGRESTORE(8)