Thank you for being a valued part of the CNET community. As of December 1, 2020, the forums are in read-only format. In early 2021, CNET Forums will no longer be available. We are grateful for the participation and advice you have provided to one another over the years.

Thanks,

CNET Support

General discussion

"private" mal-script?

Mar 26, 2008 12:51AM PDT

Obviously what i don't know could fill many billions of volumes. That said, yesterday i was making a backup copy onto a cd of some Quicktime mpgs ( i own and operate an iMac PPC3, slot loading computer, with 700 MHz and 768 MB SDRAM and my operating system is OS X 10.3.9) As i like to keep these things kind of organized, i had created a little file folder to temporarily contain the individual files i wished to copy to disc. As i have a fairly small limit (roughly 660 Mb) in how much data i can burn onto one of these backup storage discs, i would check file size of my created folder from time to time to make sure it hadn't exceeded that limit. Then i noticed a discrepancy between the amount (in Mb) of information of the contents (if i used file>get info on the outside of the highlighted file folder) and the actual content inside of it (when i would just highlight together all the individual files themselves). i expect the enclosing folder to be using 4 or maybe 8, possibly even 32 kb. But in this case, the folder alone came to 128 Mb. Curious and curiouser, i tried using the Command Find on the named folder and included invisible in my search. The were a great many things there but the one that got my attention the most was file called: "private" and within this, i saw some references to sendmail and root. Most of these things are incomprehensible to me as to cause and effect, but i emptied the contents onto the backup disc and burned that much (since it did not contain the extra 128 Mb. And then i deleted them and checked the File>info. Still 128 Mb there, all invisible. So then i deleted the folder itself. After this i restarted and "zapped the pram". Following this, i used the repair permissions utility and as it was humming along i noticed that it had a : "we are using a special UID for the file or directory/private/var/at/jobs" and another: "we are using" message : /private/var/at/spool right below that. Has something in this "private" been spying on me and attempting to send what it found to someone using some kind of script i may have downloaded along with other "helpful" free software ?. There are scads more information in that "private". All kinds of rules and definitions i don't know what to make of. What if anything ought i make of this ? i DO have "little snitch" installed to let me know when some port is about to be opened but usually i don't know what to make of these either and so just grant the permission blindly hoping for the best. Am i (again) being too paranoid or is there some cause for concern ?

Discussion is locked

- Collapse -
Paranoid?
Mar 26, 2008 9:54PM PDT

Sometimes they really are out to get you but in this case, No.

Unix, on which I am not an expert, has many directories and sub directories and in the OS X version of Unix, a whole bunch of them are invisible.

Bob knows a lot more about this than I, hopefully he will take a look at your post.

On the folder size thing. If you remember back to the halcyon days of floppy disks, you will remember that a 1K file on a floppy occupied 8K, 16K or 32K when it was transferred to your HD.
It didn't just grow, it was caused by that file taking up one block on the disk and only one item per block being allowed.
Not sure that is the case here as a newly created, empty, folder on my 500Gb shows as 0K, but goes to 8K when something is put inside it and then removed. There are a number of invisible files, desktop database for instance, that are created when you put items inside a folder.
128 does seem a lot but we do not know what size drive you have or how it is formatted.

P

- Collapse -
This looks proper to me.
Mar 26, 2008 10:14PM PDT

"we are using a special UID for the file or directory/private/var/at/jobs"

I'm not going to explain this thoroughly but will write that it is proper for the CRON "jobs" to not use your UID and to use a system account UID or a special one. There is nothing wrong about this and it's all about a design that is more about security than much else. You would not want anyone to be able to inject files into that directory and fake the cron to run it.

Bob