Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Scanvirus design flaw, NTFS support

  1. #1

    Default Scanvirus design flaw, NTFS support

    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.

  2. #2
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,773
    Blog Entries
    2

    Default Re: Scanvirus design flaw, NTFS support

    Quote Originally Posted by lord_valarian View Post
    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

  3. #3

    Default Re: Scanvirus design flaw, NTFS support

    Quote Originally Posted by tsu2 View Post
    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.

    Code:
    >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.

  4. #4
    Join Date
    Sep 2012
    Posts
    5,921

    Default Re: Scanvirus design flaw, NTFS support

    Quote Originally Posted by lord_valarian View Post
    Is NTFS fully supported?
    Until Microsoft provides either driver or official specification it can never be fully supported.

  5. #5
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,773
    Blog Entries
    2

    Default Re: Scanvirus design flaw, NTFS support

    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
    Code:
    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

  6. #6
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,773
    Blog Entries
    2

    Default Re: Scanvirus design flaw, NTFS support

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

    TSU

  7. #7

    Default Re: Scanvirus design flaw, NTFS support

    Quote Originally Posted by arvidjaar View Post
    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.

  8. #8

    Default Re: Scanvirus design flaw, NTFS support

    Quote Originally Posted by tsu2 View Post
    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
    Code:
    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.

  9. #9
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,773
    Blog Entries
    2

    Default Re: Scanvirus design flaw, NTFS support

    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

  10. #10

    Default Re: Scanvirus design flaw, NTFS support

    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.

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •