cancel
Showing results for 
Search instead for 
Did you mean: 

Query on FIND command -typo

pandora_1
Frequent Advisor

Query on FIND command -typo

Hi all,

ON a HPUX 11.23 , From an oracle UID a FIND command is executed mistakenly with a typo Error from root (/). I would like to know what the below command would have executed.

$ find . '*.xml' -mtime +2 -exec mv {} /cbrman1/test/audit_fles \;

It said Permission denied for files under /etc/ and still copied some files to /cbrman1/test/audit_fles. But none of the files where MOVED,immedietely we interrupted the command. but it had copied some files from /etc/, /etc/rc.config.d to /cbrman1/xxxxx/xx(without MOVE)

Just need to know what had happened or what impact it would be. Till now, no issues on the server or RAC database. What does this COMMAND represent
7 REPLIES
Matti_Kurkela
Honored Contributor

Re: Query on FIND command -typo

Assuming the command was executed as the oracle user in the root directory, exactly as written:

$ find . '*.xml' -mtime +2 -exec mv {} /cbrman1/test/audit_fles \;

That command would have gone through all files and sub-directories of the root directory because of "." (i.e. everything) and all files or directories named "*.xml" within the root directory (yes, that's redundant).

It would have recursed into sub-directories without limit, looking for files or directories whose time of last modification was more than 2 full days ago.

It would have attempted to move any files and directories matching the modification time criteria to /cbrman1/test/audit_files, one by one.

I would guess /cbrman1 is a filesystem mount point. A move operation from one filesystem to another is equivalent to making a copy + removing the original.

Of course, the oracle user would have required certain permissions to do so:
- read and access permissions (r-x) to a directory to go through its contents
- permission to read a file (r) to make a duplicate of it to a different filesystem
- full access to any source directory (rwx) to delete any of its contents
- at least write + access permissions to the destination directory to write anything to it (-wx)

Because most of /etc is normally readable and accessible by all users (but not writeable by anyone but root), the mv command could make the copies. But the permissions should have prevented it from deleting the original files. This is probably what caused the majority of the "Permission denied" messages.

Since the older "-exec ... \;" syntax was used, the find command would have created one "mv" command for each file or sub-directory satisfying the modification time condition. This is much less efficient than the newer "-exec ... \+" syntax... which turned out to actually be an advantage in this case.

Besides that the command was run in a wrong directory, I see another possible mistake: instead of

find . '*.xml' ...

the command should most likely have been

find . -name '*.xml' ...

This would have further restricted the command to move only files (or directories) whose name has the '.xml' suffix.

You can see what the command attempted to do by adding "echo" to the -exec command line, like this:

$ find . '*.xml' -mtime +2 -exec echo mv {} /cbrman1/test/audit_fles \;

This will display a long list of "mv /cbrman1/test/audit_fles" commands, instead of actually executing them.

A good safety procedure when constructing "find -exec ..." -style commands is to always prefix the -exec command part with "echo", running the command and reviewing the output to see if it actually does what you want. After the review, remove the "echo".

MK
MK
Dennis Handly
Acclaimed Contributor

Re: Query on FIND command -typo

>MK: This is much less efficient than the newer "-exec ... +" syntax.

You can only use that syntax if that "{}" is at the end. You must write a script that moves the last parm before the first.
pandora_1
Frequent Advisor

Re: Query on FIND command -typo

Thanks a ton for the reply. Good suggestion on echo, but it doesnt shows the permission denied here. So this command will execute even '-name' option is not given. Will it not show syntax error etc..? Well it is real danger. If it had been executed on root ID-Wouldn't that be a great impact/mess ?

Regards
Azad
Matti_Kurkela
Honored Contributor

Re: Query on FIND command -typo

> Good suggestion on echo, but it doesnt shows the permission denied here.

That means all your "permission denied" errors came from the "mv" commands trying to read or delete some file and not having the appropriate permissions.

> So this command will execute even '-name' option is not given. Will it not show syntax error etc..?

No syntax errors, because the command is syntactically valid also without the -name option. Of course, without the option, the meaning is different.

The synopsis of the 'find' command is listed on find(1) man page as:

find [-H|-L] pathname_list [expression]

Let's look at the command, both with and without the '-name' option:

> find . -name '*.xml' ...

Here, the pathname_list part contains only a single element, the current directory. All the rest belongs to the expression part.

> find . '*.xml' -mtime +2 ...

Here, the pathname_list contains multiple elements: the first element is the current directory, and the next is '*.xml'. The find command will process all the pathname_list elements in sequence. It won't stop you if you effectively specify the same thing twice: you might have done it on purpose, after all.

> If it had been executed on root ID-Wouldn't that be a great impact/mess ?

Definitely. Because the command would have moved essential system files and directories like /etc/passwd, it would probably have been impossible to log in. The command might have proceeded to /lib and/or /sbin too: eventually it would have moved /lib/libc.*, after which the regular '/usr/bin/mv' command (and most other commands) would have started to fail.

If the command had processed /sbin before /lib, then /sbin/sh would have been gone and it would not have been possible to reboot the system, even into single user mode. It would have been necessary to boot the system in recovery mode using the installation media to even begin the recovery.

You avoided a system-wide disaster because that command was *not* run as root.

This is exactly why one of the standard recommendations for Unix system administrators is to create separate users for applications (the installation process of Oracle practically forces you to do that) and to grant the appropriate permissions for application files and directories so that the needless use of the root account can be minimized.

MK
MK
pandora_1
Frequent Advisor

Re: Query on FIND command -typo

Hi Duncan,

I have attached some more outputs on VG for your reference.

YES the VGFLP is presented from EVA SAN 5000 as one LUN.

How would you map device 0x036000, as c3t6d0. Well I couldn't see any type of Harware error or light? How do we check if its gone bad.
I tried using
dd if=/dev/rdsk/c3t6d0 of=dev/null bs=1024. But still its running. One time it came out ,but second time I had a run and still going on. Hope there is no impact on running this. I tend to get more of SCSI errors.

Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1539104, sectno: 3078208, offset: 1576042496, bcount: 16384.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 4096,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1539096, sectno: 3078192, offset: 1576034304, bcount: 4096.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 16384,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1538828, sectno: 3077656, offset: 1575759872, bcount: 16384.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 4096,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1538776, sectno: 3077552, offset: 1575706624, bcount: 4096.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 8192,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1538768, sectno: 3077536, offset: 1575698432, bcount: 8192.
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1538740, sectno: 3077480, offset: 1575669760, bcount: 8192.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Read error -- dev: b 31 0x036000, errno: 126, resid: 1024,
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 8192,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 8, sectno: 16, offset: 8192, bcount: 1024.
Jun 1 11:31:50 dopdwdb2 vmunix: LVM: VG 64 0x000000: PVLink 31 0x036000 Failed! The PV is not accessible.
Jun 1 11:31:50 dopdwdb2 vmunix:
Jun 1 11:31:56 dopdwdb2 above message repeats 79 times
Jun 1 11:31:55 dopdwdb2 vmunix: LVM: VG 64 0x000000: PVLink 31 0x036000 Recovered.
pandora_1
Frequent Advisor

Re: Query on FIND command -typo

Ignore last comment please
pandora_1
Frequent Advisor

Re: Query on FIND command -typo

MK...Thanks for the reply.Very well elobarated and useful.