Re: Hidden files
On Tue, Jun 06, 2006 at 05:00:26PM +0300, Linas ??virblis wrote: Mike Hommey wrote: Could you tell us what kind of harm can do a hidden empty file in /usr ? First of all, false positives in rootkit and security scanners. And too many false positives lead to false negatives sooner or later. That's a bug in the rootkit and/or host-based scanner. A hidden file is in no way indication of a rootkit or malicious software installed. Sure, some rootkits do use hidden files, but if you have a rootkit-detector software you don't want to flag a *big* alarm [1] if you see any of those. Regards Javier [1] Tiger, which could be considered a host-based security scanner, will flag a *medium* alarm in some instances of hidden files but will not inmediately say that's a security issue. signature.asc Description: Digital signature
Re: Hidden files
Scripsit Klaus Ethgen [EMAIL PROTECTED] There are two reasons not to use hidden files in /usr, /var, /dev and other: 1. It generates false positives (as mention before). And to many false positives only ends in overlook the real bad files and directories. 2. There is absolutely no reason to hide think in this directories. The underlying bug seems to be the entire concept of hidden files. It seems to me that on the whole they cause far more trouble than they help. If they are only supposed to be in $HOME (and a tidy $HOME should contain nothing but dotfiles and subdirectories anyway), it is rather excessive to let the hiddenness work everywhere else in the system. It's a pity that this is fundamentally unfixable because there is no knowing how many little scripts everywhere that depend on ls filtering out hidden files. But I don't think I have ever used ls from an interactive shell _without_ the -a flag. -- Henning Makholm The compile-time type checker for this language has proved to be a valuable filter which traps a significant proportion of programming errors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
On Wed, Jun 07, 2006 at 12:02:23AM +0100, Roger Leigh wrote: Ron Johnson [EMAIL PROTECTED] writes: Just as /etc/bashrc is not hidden, whereas ~/.bashrc is, *why* should any *system* files be hidden? IMO dotfiles are a historical artifact which we are stuck with. If we were just starting today, I'm sure we would be using ~/etc/bashrc rather than ~/.bashrc so the user's files match the standard locations. It's logical, simple, and would make many things easier. This argument is valid only for configuration. There are more reasons to have files which are not displayed unless you ask for them. For example: * .svn Storing this metadata somewhere else would mean you have to explicitely purge it every time you do something as basic as deleting a dir. Also, you are no longer free to move things around by hand, can't move them to another machine without some kind of export/import, and so on, so on. * .xvpics It takes a long time to show the thumbnails, so caching them is not a bad idea. However, if this cache was placed anywhere else than the dir which contains the images, thumbnails would accumulate indefinitely -- with .xvpics, deleting the directory removes the relevant cache without any extra effort. While historical reasons are acceptable for users' dotfiles, I remain to be convinced that there is a logical rationale for them in any system location, or even anywhere under $HOME except the root. Showing dotfiles by default doesn't provide you with any extra security. The rootkit can as easily use /var/lib/dpkg/info/ or even /mnt/win/Windows/System32/hidden\ from\ mom/pr0n/. Also, unlike Sony's rootkit, dotfiles are hidden only from tools that explicitely remove them from the output -- that is, ls, mc or nautilus but not find. Dotfiles are just a means of hiding visual spam. The less irrelevant information is forced into your eyes, the more attention you have left for real work. And -a is just three keystrokes anyway. On the other hand, the issue which started this thread _is_ valid IMHO. /usr/lib/xulrunner/.autoreg is not metadata you're not going to look for but a file that is not really different from, let's say, no_ppp_on_boot. A marker that is a functional part of xulrunner and that is usually important to those who bother to take a look at the relevant dir. Note that I think you're right because of semantics, not because of broken security scanners. Regards, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
On Wed, Jun 07, 2006 at 10:45:28AM +0200, Adam Borowski wrote: This argument is valid only for configuration. There are more reasons to have files which are not displayed unless you ask for them. For example: * .svn Storing this metadata somewhere else would mean you have to explicitely purge it every time you do something as basic as deleting a dir. Also, you are no longer free to move things around by hand, can't move them to another machine without some kind of export/import, and so on, so on. * .xvpics It takes a long time to show the thumbnails, so caching them is not a bad idea. However, if this cache was placed anywhere else than the dir which contains the images, thumbnails would accumulate indefinitely -- with .xvpics, deleting the directory removes the relevant cache without any extra effort. These two are examples of files that can occur everywhere, rather than in $HOME. While caching purposes and/or metadata are certainly valid reasons to hide files away, I don't think that storing configuration is just as valid. Moreover, your problem about removing cache with a directory can be easily worked around by using some cache expiry algorithm. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
I demand that Henning Makholm may or may not have written... [snip] But I don't think I have ever used ls from an interactive shell _without_ the -a flag. I use -A rather than -a - it filters out . and ... -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. Beware the thirty-first of November. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Henning Makholm [EMAIL PROTECTED] writes: But I don't think I have ever used ls from an interactive shell _without_ the -a flag. I use -a (or -A) very, very rarely. (Not that I don't agree that the concept of hidden files should be replaced by using ~/etc/ for dotfile, but when we do this, we should start fixing other hysterical raisins as well. Gobolinux made a nice start in that regard, for example. But I think it is out of scope for Debian.) Regards, -- Jorgen -- Debian GNU/Linux Developer [EMAIL PROTECTED] http://www.forcix.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hidden files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, more and more packages use hidden files in /usr. I see this as an error. But before making a bug report for such packages I wish to ask if this is intended or really a bug? Some of the files are in the package some are created in postinst and not registered to any package. I see ANY hidden file in /usr as a bug which should be fixed! Packages are: - - kaffe - - blender - - firefox - - libnss3-0d or libxul0d (/usr/lib/xulrunner/.autoreg) Regards Klaus Ethgen - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iQEVAwUBRIVPHp+OKpjRpO3lAQK+WAf8DGUJ9p7Ne5E4BIiNc5Ds69NF0WP05qsT PiqM7QXW4ls/sDFYRP4XIGQlW2FG0E7XFfqHYv/c3gI8xmKORf/3I7XDF5INu6NV gQrcD1b9f9jSbphnpqt/GqKxlWHv4nqEcjJZribHuyssFLa6rm6uMaLYUT01KdBc pSrROnqg0nPwM6NmtzhaFM1Uhjm6/CrPIlSzG2nZb2OTDYloLVW7w9Oa74diBOuT vexnTwZhXLHG1k5kT4yg/hC1J/nptLJqtZ6FIrkDzQrzU4XfpHhuAdf3eF8hHGsm IHoASnHZ3tQs2/8H4W29OOt6gYYEfbLn+aYvGL2wln4sQfVS3VA4cw== =jV2+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
On Tue, Jun 06, 2006 at 11:47:10AM +0200, Klaus Ethgen [EMAIL PROTECTED] wrote: Hello, more and more packages use hidden files in /usr. I see this as an error. But before making a bug report for such packages I wish to ask if this is intended or really a bug? Some of the files are in the package some are created in postinst and not registered to any package. I see ANY hidden file in /usr as a bug which should be fixed! Packages are: - firefox - libnss3-0d or libxul0d (/usr/lib/xulrunner/.autoreg) I can speak for these two. This is not a bug but an intended feature. It helps component registration on upgrade. The file could be renamed, but that means modifying mozilla's code. Not that we don't already modify it, but if we can avoid to make too many changes, it's still better. Could you tell us what kind of harm can do a hidden empty file in /usr ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Mike Hommey wrote: Could you tell us what kind of harm can do a hidden empty file in /usr ? First of all, false positives in rootkit and security scanners. And too many false positives lead to false negatives sooner or later. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
On 6/6/06, Mike Hommey [EMAIL PROTECTED] wrote: On Tue, Jun 06, 2006 at 11:47:10AM +0200, Klaus Ethgen [EMAIL PROTECTED] wrote: Hello, more and more packages use hidden files in /usr. I see this as an error. But before making a bug report for such packages I wish to ask if this is intended or really a bug? Some of the files are in the package some are created in postinst and not registered to any package. I see ANY hidden file in /usr as a bug which should be fixed! Packages are: - firefox - libnss3-0d or libxul0d (/usr/lib/xulrunner/.autoreg) I can speak for these two. This is not a bug but an intended feature. It helps component registration on upgrade. The file could be renamed, but that means modifying mozilla's code. Not that we don't already modify What about an upstream 'feature' request? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
On Tue, 06 Jun 2006, Mike Hommey wrote: Could you tell us what kind of harm can do a hidden empty file in /usr ? It flags alarms, it is obscure, and generally it is bad form to have hidden files anywhere but under user homes anyway. There certainly is no excuse to have anything hidden inside the system hierarchies, you WANT to easily know what is there. Please consider this email as a second request that those files be renamed to something without a leading dot. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Henrique de Moraes Holschuh wrote: It flags alarms, it is obscure, and generally it is bad form to have hidden files anywhere but under user homes anyway. There certainly is no excuse to have anything hidden inside the system hierarchies, you WANT to easily know what is there. Sure there is. For example, mooix uses .mooix as a flag file in directories that are mooix objects, and uses other dotfiles inside objects for fields that are only accessible by methods of that object and are hidden from casual interspection (as opposed to public fields). Some mooix objects live under /usr, some under /var, and some in user home directories, it wouldn't make sense to rename all the fields in the objects that are installed under /usr. If you want to know what's really there, use ls -a .. -- see shy jo signature.asc Description: Digital signature
Re: Hidden files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Di den 6. Jun 2006 um 18:12 schrieb Joey Hess: If you want to know what's really there, use ls -a .. This is not the point. I think no of us do not know how to show that files. There are two reasons not to use hidden files in /usr, /var, /dev and other: 1. It generates false positives (as mention before). And to many false positives only ends in overlook the real bad files and directories. 2. There is absolutely no reason to hide think in this directories. If a programming method use dot files to make there classes and methods private -- no problem. But is it necessary to put them in common paths? I think this is more a misuse. Finished programs should be compiled in some way. Regards Klaus Ethgen - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iQEVAwUBRIWyaZ+OKpjRpO3lAQJLcwf9Hddd96EmUISBjK8NlXh027JAHcy4duXy NOkJlXQTTT8IqwTRLWXK4CYOCVemWQHgrfy9dWkkXcKuGeRvAQ8v/RlpdySkwCSR RNJYvZ63GGaqbkNydlvyU+3R4mYaTWotXwF4u5KiKcJlLXWVT4vkTb9iS7k4yFf9 9UdDnq+8BAkTLRYaw0XmlGMVL05jb5k3VeYPw6hTfrtRhhabnV0ArLl0aFtWKRXi exgrTgMXA3GbsxIkZyzaikciKrCfRIsHqlpeo2kmndvKLj8XdePw8XrwXYMfuAFc FzuNE1uCIi883aUdWzoCBXuhD+swGqqFJR8+e8cSiFvrKuJXRM5CtA== =wGqe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Klaus Ethgen wrote: 1. It generates false positives (as mention before). And to many false positives only ends in overlook the real bad files and directories. Scanning for dotfiles is not an effective way to find files left behind by exploits. People writing exploits are aware of programs that warn about dotfiles, and it's easy to find other places to hide troublesome files. I'd probably use /var/lib/dpkg/info/ on Debian systems if I were writing an exploit; the high churn rate of new files in that directory coupled with the absurd number of files in it make it an excellent hiding place. 2. There is absolutely no reason to hide think in this directories. If a programming method use dot files to make there classes and methods private -- no problem. But is it necessary to put them in common paths? I think this is more a misuse. Finished programs should be compiled in some way. The example I saw was of a dotfile in /usr/lib/something/ not /usr/bin. -- see shy jo signature.asc Description: Digital signature
Re: Hidden files
Joey Hess [EMAIL PROTECTED] writes: Henrique de Moraes Holschuh wrote: It flags alarms, it is obscure, and generally it is bad form to have hidden files anywhere but under user homes anyway. There certainly is no excuse to have anything hidden inside the system hierarchies, you WANT to easily know what is there. Sure there is. For example, mooix uses .mooix as a flag file in directories that are mooix objects, and uses other dotfiles inside objects for fields that are only accessible by methods of that object and are hidden from casual interspection (as opposed to public fields). It is always bad practice to hide things from the user or system administrator, particularly outside their $HOME. If you need to store additional metadata about files or directories, you really should be using POSIX 1003.1e extended attributes. It's supported by glibc. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpDdFCMmwvkg.pgp Description: PGP signature
Re: Hidden files
Hi, On Tue, Jun 06, 2006 at 11:05:31AM -0300, Henrique de Moraes Holschuh wrote: It flags alarms, it is obscure, and generally it is bad form to have hidden files anywhere but under user homes anyway. There certainly is no excuse to have anything hidden inside the system hierarchies, you WANT to easily know what is there. Please consider this email as a second request that those files be renamed to something without a leading dot. Make that three requests. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Hidden files
On Tue, 2006-06-06 at 18:54 +0100, Roger Leigh wrote: It is always bad practice to hide things from the user or system administrator, particularly outside their $HOME. Indeed, I'd call that ``the principle of least surprise''. Thijs signature.asc Description: This is a digitally signed message part
Re: Hidden files
On Tue, Jun 06, 2006 at 08:32:34PM +0200, Uwe Hermann [EMAIL PROTECTED] wrote: Hi, On Tue, Jun 06, 2006 at 11:05:31AM -0300, Henrique de Moraes Holschuh wrote: It flags alarms, it is obscure, and generally it is bad form to have hidden files anywhere but under user homes anyway. There certainly is no excuse to have anything hidden inside the system hierarchies, you WANT to easily know what is there. Please consider this email as a second request that those files be renamed to something without a leading dot. Make that three requests. It'd be easier to take your claim into account if you actually brought better facts than I don't like it or stupid tools give false positives Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Mike Hommey wrote: It'd be easier to take your claim into account if you actually brought better facts than I don't like it or stupid tools give false positives Let us imagine someone decides to introduce package X that contains a lot of files (let us say 50) in /usr/lib and half of them are dot files. And what about shipping hidden directories? Would such packages be accepted into Debian? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
On Tue, Jun 06, 2006 at 10:51:02PM +0300, Linas Žvirblis [EMAIL PROTECTED] wrote: Mike Hommey wrote: It'd be easier to take your claim into account if you actually brought better facts than I don't like it or stupid tools give false positives Let us imagine someone decides to introduce package X that contains a lot of files (let us say 50) in /usr/lib and half of them are dot files. And what about shipping hidden directories? Would such packages be accepted into Debian? Here, we are talking about the empty file /usr/lib/xulrunner/.autoreg... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Mike Hommey wrote: Here, we are talking about the empty file /usr/lib/xulrunner/.autoreg... Are you saying it is fine for empty files? So what about /usr/lib/kaffe/.system (a symlink to directory) or /usr/lib/jvm/.java-gcj.jinfo (non-empty file)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Linas Žvirblis wrote: Let us imagine someone decides to introduce package X that contains a lot of files (let us say 50) in /usr/lib and half of them are dot files. And what about shipping hidden directories? Would such packages be accepted into Debian? I've had packages in Debian with more dotfiles than that in /usr/lib (although only perhaps 5% of the total file count). -- see shy jo signature.asc Description: Digital signature
Re: Hidden files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joey Hess wrote: Linas ?virblis wrote: Let us imagine someone decides to introduce package X that contains a lot of files (let us say 50) in /usr/lib and half of them are dot files. And what about shipping hidden directories? Would such packages be accepted into Debian? I've had packages in Debian with more dotfiles than that in /usr/lib (although only perhaps 5% of the total file count). Just my humble opinion, but hidden system files just smacks of the Sony DRM rootkit debacle. Just as /etc/bashrc is not hidden, whereas ~/.bashrc is, *why* should any *system* files be hidden? Nevertheless, IMO these changes and arguments should be made upstream. - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEhgOjS9HxQb37XmcRAtHKAKClkbZqmJtuVoCGatf6GVEyAYmvIgCfcZaQ n9GUEECNl3fPr+YzF60mcfY= =aqY5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Ron Johnson [EMAIL PROTECTED] writes: Joey Hess wrote: Linas ?virblis wrote: Let us imagine someone decides to introduce package X that contains a lot of files (let us say 50) in /usr/lib and half of them are dot files. And what about shipping hidden directories? Would such packages be accepted into Debian? I've had packages in Debian with more dotfiles than that in /usr/lib (although only perhaps 5% of the total file count). Just my humble opinion, but hidden system files just smacks of the Sony DRM rootkit debacle. Just as /etc/bashrc is not hidden, whereas ~/.bashrc is, *why* should any *system* files be hidden? IMO dotfiles are a historical artifact which we are stuck with. If we were just starting today, I'm sure we would be using ~/etc/bashrc rather than ~/.bashrc so the user's files match the standard locations. It's logical, simple, and would make many things easier. While historical reasons are acceptable for users' dotfiles, I remain to be convinced that there is a logical rationale for them in any system location, or even anywhere under $HOME except the root. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpYuET3esKLa.pgp Description: PGP signature
Re: Hidden files
Roger Leigh [EMAIL PROTECTED] wrote: IMO dotfiles are a historical artifact which we are stuck with. If we were just starting today, I'm sure we would be using ~/etc/bashrc rather than ~/.bashrc so the user's files match the standard locations. It's logical, simple, and would make many things easier. While historical reasons are acceptable for users' dotfiles, I remain to be convinced that there is a logical rationale for them in any system location, or even anywhere under $HOME except the root. For most cases I agree, there's little point to it, but I don't think they pose a real security risk either. I mean, find will reveal them by default, and for the really security-concious, it's easy to alias ls to ls -a. And I can see a use for them in global directories, for files that you should not modify unless you *really* know what you are doing. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Roger Leigh [EMAIL PROTECTED] writes: While historical reasons are acceptable for users' dotfiles, I remain to be convinced that there is a logical rationale for them in any system location, or even anywhere under $HOME except the root. It's way too much of a pain to modify upstream code that uses files beginning with '.' for reasons that are essentially cosmetic. Passing along the request to upstream makes perfect sense. I would recommend using _ instead of . if they want to put the file into a clearly separate namespace. But if upstream doesn't bite, I'd say that this is the sort of divergence and maintenance burden that Debian really doesn't need. The advantages are not compelling enough, IMO. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
