Scanvirus design flaw, NTFS support

[lord_valarian]

opensuse leap 42.1 - KDE

http://linux.die.net/man/1/clamscan
--move=DIRECTORY Move infected files into DIRECTORY. Directory must be writable for the '' user or unprivileged user running 'clamscan'.

Scanvirus script must be run in superuser mode. First, I need to move files to the user's (who called it) home directory. I've been having problems getting a blank string.

clamscan -r $windows_folder --move=$HOME/VirusVault/


Does opensuse leap 42.1 support writing to NTFS mounted drives? I'v had problems with the files moved into the vault. They might be false positives, so they go into the the vault.

[tsu2]

opensuse leap 42.1 - KDE

http://linux.die.net/man/1/clamscan
--move=DIRECTORY Move infected files into DIRECTORY. Directory must be writable for the '' user or unprivileged user running 'clamscan'.

Scanvirus script must be run in superuser mode. First, I need to move files to the user's (who called it) home directory. I've been having problems getting a blank string.

clamscan -r $windows_folder --move=$HOME/VirusVault/


Does opensuse leap 42.1 support writing to NTFS mounted drives? I'v had problems with the files moved into the vault. They might be false positives, so they go into the the vault.

I encountered similar issues in a recent script I wrote, some things for you to look at...

- Your proposed script cannot be run as "su" but should succeed using "sudo" otherwise $HOME will point to root's home folder instead of your normal User account's folder (unless that's your intention)
- I've been playing around with the idea of "su $USER" to change to the normal User's security context, but so far when invoked the script stops instead of continuing. Maybe someone else or you can find the solution to that.

TSU

[lord_valarian]

I encountered similar issues in a recent script I wrote, some things for you to look at...

- Your proposed script cannot be run as "su" but should succeed using "sudo" otherwise $HOME will point to root's home folder instead of your normal User account's folder (unless that's your intention)
- I've been playing around with the idea of "su $USER" to change to the normal User's security context, but so far when invoked the script stops instead of continuing. Maybe someone else or you can find the solution to that.

TSU

IC. This should fix my problem then? I have to retest over and over. So, this is good for users, but impractical for testing. This is only an issue if I move files to the virus vault in the user's home directory.

>sudo scanvirus -w

Is NTFS fully supported? In the past, Windows said 'partition needs integrity checking'. It ran though the steps and worked fine. Now, windows doesn't complain when I move files. However, Linux sometimes delete files transferred or act strangely. Because of that, I don't have any virus test files now.

[arvidjaar]

Is NTFS fully supported?

Until Microsoft provides either driver or official specification it can never be fully supported.

[tsu2]

I guess I don't understand how your question relates to NTFS and why you're asking about it.

When you copy, move or write to a location, your script's security context is all that's necessary.

And, when you're talking about a virus scan type app, it won't matter what file systems exist... Only that files can be read.
Are you scanning(reading) files on an NTFS file system? That shouldn't be an issue. The Linux NTFS driver should be good enough to do that unless you configure the NTFS file properties to explicitly deny.

Do you have your ~/VirusVault folder created already (and of course you must be precise with your camel case)?
If you write to a location that doesn't already exist, the folder won't automagically appear.

You should also check the values of your variables using echo, eg

echo $HOME
echo $windows_folder

If those values are supposed to exist before you run your script, then you can just invoke in a console.
If your scan command is embedded in a larger script, then you can embed these commands just before you scan to see whether they have the correct values then.

TSU

[tsu2]

If you actually <move> a file,
Then you do need delete permissions on the original file and location.

TSU

[lord_valarian]

Until Microsoft provides either driver or official specification it can never be fully supported.

I'v copied between FAT32 and linux with no problems. NTFS only has problem if I have illegal characters. K3B often leaves illegal characters when I rip cd's: ") . When you copy from linux to NTFS, it deletes files with those characters during a file check. I have to manual fix them before I transfer them.

I Get Weak 12" version (2009 remaster) file deleted.

[lord_valarian]

I guess I don't understand how your question relates to NTFS and why you're asking about it.

Note above response.

When you copy, move or write to a location, your script's security context is all that's necessary.

And, when you're talking about a virus scan type app, it won't matter what file systems exist... Only that files can be read.
Are you scanning(reading) files on an NTFS file system? That shouldn't be an issue. The Linux NTFS driver should be good enough to do that unless you configure the NTFS file properties to explicitly deny.

OK. 'scanvirus' clam scans both 'VFAT' and 'NTFS' file types. I have both options "scan only" or "move to virus vault". Any files moved often disappear from that directory. /$HOME/$USER/VirusVault FYI, I'm nearly finished with beta2.

Changing virusvault to 'root/tmp/VirusVault' Should fix the problem with the variables $HOME and $USER. The virusvault file problem will have to wait until test it with opensuse leap.

Do you have your ~/VirusVault folder created already (and of course you must be precise with your camel case)?
If you write to a location that doesn't already exist, the folder won't auto-magically appear.

You should also check the values of your variables using echo, eg

echo $HOME
echo $windows_folder

If those values are supposed to exist before you run your script, then you can just invoke in a console.
If your scan command is embedded in a larger script, then you can embed these commands just before you scan to see whether they have the correct values then.

TSU

Yes. $HOME= '/ROOT' and $USER= '/NULL' 'VirusVault' is created in the user's directory by the '--setup' function which isn't working anymore. Using the linux system '/tmp', should fix the problem. I just have tell the user where the directory is located. They can copy any files if needed.

Thanks.

[tsu2]

Recommend you avoid any confusion and stop using variables for your locations, particularly if the locations aren't dependent on the identity of the logged in User. Just specify hard paths and ensure your script is running with sufficient permissions to create/read/write to those locations and additionally delete for the scanned locations.

This assumes you are writing your script to support <only> openSUSE. Of course, if you intend to support multiple distros then paths and convention will likely differ.

TSU

[lord_valarian]

If you actually <move> a file,
Then you do need delete permissions on the original file and location.

TSU

If a virus file write protects itself, that means I need remove write protection then attempt to move it again?

Recommend you avoid any confusion and stop using variables for your locations, particularly if the locations aren't dependent on the identity of the logged in User. Just specify hard paths and ensure your script is running with sufficient permissions to create/read/write to those locations and additionally delete for the scanned locations

In superuser, I can just check for the 'tmp' directory and create it if not present. Then check for 'tmp/VirusVault' if not present.

This assumes you are writing your script to support <only> openSUSE. Of course, if you intend to support multiple distros then paths and convention will likely differ.

I'm limiting it to bash script. I'm trying to make it as flexible as possible (printf, if, then, elif, fi, echo). For now, I want to just get it working.

It works, but can't handle space in filenames. IFS won't work, it goes from 1 to string length. I need to go string length to the first ':'. I know there be any extra ':' going string Length to 1. I need to access the string character one by one.

string1='hello there...'

${stringvar#} = string length

${stringvar[0]} = 'h'?


I can use the gawk substring to get the string out, reading that now.