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'
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 &qu
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
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
> expli
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
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
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
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
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 pa
-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 pa
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 m
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 PROTEC
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
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 the
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
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
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 hierarc
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 s
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 t
-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, /v
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.
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
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
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
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? Som
-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
26 matches
Mail list logo
