gmane.linux.debian.devel.general

alex bodnaru | 19 Aug 07:20

Bug#495628: general: setting system users' homes in their data directory slower security scanning

Package: general
Severity: normal

putting the home directory of users like postgres or especially backuppc 
in their data directory makes routine scans of tiger over the homes directory 
for user related suspect files work significantly slower.

there is no reason to scan those directories, since they contain structured 
data only, but only accidental logins of those users may bring bad thing here, 
and this should be the second reason not to set their homedirs here.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

headers

Christian Perrier | 19 Aug 09:45

Bug#495628: general: setting system users' homes in their data directory slower security scanning

Quoting alex bodnaru (alexbodn <at> 012.net.il):
> Package: general
> Severity: normal
> 
> putting the home directory of users like postgres or especially backuppc 
> in their data directory makes routine scans of tiger over the homes directory 
> for user related suspect files work significantly slower.
> 
> there is no reason to scan those directories, since they contain structured 
> data only, but only accidental logins of those users may bring bad thing here, 
> and this should be the second reason not to set their homedirs here.

Why don't you discuss this with the respective maintainers of these
packages?

I doubt that an overall policy about this is, at this very moment,
something that can really happen and I highly suspect that this bug
report just gets ignored by many (not judging its validity, which I
have no competent advice about).

headers

Bryan Donlan | 19 Aug 19:38

Bug#495628: general: setting system users' homes in their data directory slower security scanning

On Tue, Aug 19, 2008 at 1:21 AM, alex bodnaru <alexbodn <at> 012.net.il> wrote:
> Package: general
> Severity: normal
>
> putting the home directory of users like postgres or especially backuppc
> in their data directory makes routine scans of tiger over the homes directory
> for user related suspect files work significantly slower.

I'm not sure what tiger is...

> there is no reason to scan those directories, since they contain structured
> data only, but only accidental logins of those users may bring bad thing here,
> and this should be the second reason not to set their homedirs here.

... but logins for these users are disabled by default, and even if
they weren't, adding random dotfiles ought not to break anything
badly, surely?

headers

Debian Bug Tracking System | 20 Aug 07:15

Bug#495628: marked as done (general: setting system users' homes in their data directory slower security scanning)


Your message dated Wed, 20 Aug 2008 07:12:55 +0200
with message-id <20080820051255.GU21509 <at> mykerinos.kheops.frmug.org>
and subject line Re: Bug#495628: general: setting system users' homes in their data directory slower
security scanning
has caused the Debian Bug report #495628,
regarding general: setting system users' homes in their data directory slower security scanning
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner <at> bugs.debian.org
immediately.)

--

-- 
495628: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495628
Debian Bug Tracking System
Contact owner <at> bugs.debian.org with problems

From: alex bodnaru <alexbodn <at> 012.net.il>
Subject: general: setting system users' homes in their data directory slower security scanning
Date: 2008-08-19 05:21:56 GMT

(Continue reading)