On Fri, Nov 04, 2005 at 11:01:20AM -0800, Philippe Troin wrote:
Although I agree with the above on principle, how do you manage
membership to the floppy, audio, video, etc groups?
pam_group for example. If you want to let some users access the devices
even if they are not logged in at the
Gabor Gombas [EMAIL PROTECTED] writes:
On Fri, Nov 04, 2005 at 11:01:20AM -0800, Philippe Troin wrote:
Although I agree with the above on principle, how do you manage
membership to the floppy, audio, video, etc groups?
pam_group for example.
pam_group would work for floppy, audio and
Gabor Gombas [EMAIL PROTECTED] writes:
On Sat, Oct 29, 2005 at 10:21:13PM -0700, Philippe Troin wrote:
An other issue that always annoyed me is that assuming a NIS server
and a NIS client which both install say exim. I want to give some
users membership in the group Debian-exim. I
On Sat, Oct 29, 2005 at 12:46:47AM +0200, Rolf Kutz wrote:
The admin should know whether he messed with the
account and if he did just remove the package
instead of purging it. It's not like packages get
purged by themself.
Messing with the _account_ is not the same as messing with config
On Sat, Oct 29, 2005 at 10:21:13PM -0700, Philippe Troin wrote:
An other issue that always annoyed me is that assuming a NIS server
and a NIS client which both install say exim. I want to give some
users membership in the group Debian-exim. I can't easily.
The UID picked by Debian-exim is
Am 2005-10-26 14:51:00, schrieb Humberto Massa:
It seems that you still did not get my point.
My point is, in a SoHo workstation, this is exactly the most common
scenario nowadays (example: hmm. let me try this new dvd-player... I
open synaptic, install it, ... nah, it does not work as I
Am 2005-10-26 14:51:00, schrieb Humberto Massa:
It seems that you still did not get my point.
My point is, in a SoHo workstation, this is exactly the most common
scenario nowadays (example: hmm. let me try this new dvd-player... I
open synaptic, install it, ... nah, it does not work as I
Hello Humberto,
Am 2005-10-26 14:30:32, schrieb Humberto Massa:
Problem being, if daemons don't remove their (supposedly exclusive-use)
accounts, you can end in two years with 100 unnecessary accounts in a
workstation.
Realy interesting...
I have counted the System-Users on my 146
Florian Weimer wrote:
* Steve Langasek:
Frank Lichtenheld has already posted an announcement[4] detailing the
release team's plans for the question of non-DFSG documentation in main.
Just to clarify, is technical documentation that is only available in
non-editable formats (e.g.
On Sun, 30 Oct 2005 10:58:23 +1100, Brian May [EMAIL PROTECTED] wrote:
That is my point - adduser will print a warning if the user already
exists.
So you need to check to make sure the user doesn't exist first, before
attempting to add it. Or you get a stupid warning appearing when
upgrading
su, 2005-10-30 kello 10:37 +0100, Marc Haber kirjoitti:
On Sun, 30 Oct 2005 10:58:23 +1100, Brian May [EMAIL PROTECTED] wrote:
That is my point - adduser will print a warning if the user already
exists.
So you need to check to make sure the user doesn't exist first, before
attempting to add
Marc == Marc Haber [EMAIL PROTECTED] writes:
Marc On Thu, 27 Oct 2005 08:54:18 +1000, Brian May
Marc [EMAIL PROTECTED] wrote:
If the code just calls adduser, this would seem to be a bug,
as adduser will exit with a warning if the user already exists
(see #264570). (If I
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Oct 27, 2005 at 07:24:28AM -0500, Steve Greenland wrote:
On 27-Oct-05, 04:39 (CDT), Jonas Meurer [EMAIL PROTECTED] wrote:
it produces at least a bloated passwd/group/shadow file.
Bloat? The /etc/passwd on my development machine, which
* Miles Bader:
Florian Weimer [EMAIL PROTECTED] writes:
There are people in this world who can read and program PostScript.
Sure, and it's the preferred form of modifcation for removing
ink-wasting background images from Powerpoint presentations, but: This
is not the kind of modifcation
Florian Weimer [EMAIL PROTECTED] wrote:
* Frank Küster:
It is for sure not a bug to contain a PostScript file where PostScript
is the preferred form of modification. If you have tetex-base
installed, /usr/share/texmf/dvips/misc/resolution400.ps is a short
example,
Florian Weimer [EMAIL PROTECTED] wrote:
* Miles Bader:
Florian Weimer [EMAIL PROTECTED] writes:
There are people in this world who can read and program PostScript.
Sure, and it's the preferred form of modifcation for removing
ink-wasting background images from Powerpoint presentations,
* Quoting Gabor Gombas ([EMAIL PROTECTED]):
So, how can the administrator tell dpkg do _not_ remove this account
even if some package's postrm tries to purge it? If there would be a
method to mark some accounts out-of-reach for automatic removal, that
would settle this issue I think.
The
On Thu, 27 Oct 2005 08:54:18 +1000, Brian May [EMAIL PROTECTED] wrote:
If the code just calls adduser, this would seem to be a bug, as
adduser will exit with a warning if the user already exists (see
#264570). (If I am mistaken here with the precise details it is
because the man page has mislead
On Wed, 26 Oct 2005 14:15:41 +0200, Gabor Gombas [EMAIL PROTECTED]
wrote:
If you want to allow automatic user/group removal, then adduser should
be extended to remember every UID/GID that was ever used by a system
user, and never reuse them again even if they have since been removed
from
Stephen Frost [EMAIL PROTECTED] wrote:
* Don Armstrong ([EMAIL PROTECTED]) wrote:
On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote:
On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote:
What about log files with sensitive content?
Non-issue, as I said in the end of my
On Wed, 26 Oct 2005 22:38:44 +0100, Stephen Gran [EMAIL PROTECTED]
wrote:
add user
chown a bunch of stuff to the new user
start the daemon
Correct me if I'm wrong, but I'm imagining this dh_ fragment being added
by the DEBHELPER blob at the end, and so anything needed to be done
in between
On 26/10/2005 Thomas Bushnell BSG wrote:
Humberto Massa [EMAIL PROTECTED] writes:
Problem being, if daemons don't remove their (supposedly exclusive-use)
accounts, you can end in two years with 100 unnecessary accounts in a
workstation.
And what bad results does this produce?
it
On 26/10/2005 Andreas Barth wrote:
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]:
in my workstation I try out a new package (for scientfic computing, a
game for Lucas, a new development package) at least once each two days,
and a lot of times they come with their libs and their
* Bernhard R. Link:
* Florian Weimer [EMAIL PROTECTED] [051025 13:51]:
* Steve Langasek:
Frank Lichtenheld has already posted an announcement[4] detailing the
release team's plans for the question of non-DFSG documentation in main.
Just to clarify, is technical documentation that is
Florian Weimer [EMAIL PROTECTED] wrote:
* Bernhard R. Link:
* Florian Weimer [EMAIL PROTECTED] [051025 13:51]:
* Steve Langasek:
Frank Lichtenheld has already posted an announcement[4] detailing the
release team's plans for the question of non-DFSG documentation in main.
Just to
On Wednesday 26 October 2005 23:38, Stephen Gran wrote:
While I appreciate the effort at a standard shell script fragment for
'install a user', and think that it would be useful as reference and for
reuse, I tend to think making it a dh_ fragment doesn't work in the
normal use cases I can
On 27-Oct-05, 04:39 (CDT), Jonas Meurer [EMAIL PROTECTED] wrote:
it produces at least a bloated passwd/group/shadow file.
Bloat? The /etc/passwd on my development machine, which has seen all
kinds of random server installs and removes, has grown to a whole 2K.
So it could double before
On Thu, Oct 27, 2005 at 07:24:28AM -0500, Steve Greenland wrote:
On 27-Oct-05, 04:39 (CDT), Jonas Meurer [EMAIL PROTECTED] wrote:
it produces at least a bloated passwd/group/shadow file.
Bloat? The /etc/passwd on my development machine, which has seen all
kinds of random server installs
* Frank K?ster ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] wrote:
Have we actually got a specific case of this happening and there being a
real security threat from it?
When I ran a samba server years ago, I changed the default log file names
and, IIRC, location.
Were they
Stephen Frost [EMAIL PROTECTED] wrote:
* Frank K?ster ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] wrote:
Have we actually got a specific case of this happening and there being a
real security threat from it?
When I ran a samba server years ago, I changed the default log
On Wed, Oct 26, 2005 at 02:51:00PM -0300, Humberto Massa wrote:
It seems that you still did not get my point.
My point is, in a SoHo workstation, this is exactly the most common
scenario nowadays (example: hmm. let me try this new dvd-player... I
open synaptic, install it, ... nah, it does
On Thu, Oct 27, 2005 at 11:54:10AM +0200, Jonas Meurer wrote:
but we try to make packages better for our users, and one issue in doing
so is dealing with system accounts.
if a package creates a system user who is intended to be used by the
package only, the package should remove the user at
On Thu, Oct 27, 2005 at 05:53:16AM -0700, Steve Langasek wrote:
Nah, the biggest hit isn't disk space, it's NSS lookup times from having to
do a linear search through a flat-file /etc/passwd and /etc/shadow. Well,
thank God no one uses pam_pwdb anymore, at least...
One can use nscd if he/she
* Frank Küster:
It is for sure not a bug to contain a PostScript file where PostScript
is the preferred form of modification. If you have tetex-base
installed, /usr/share/texmf/dvips/misc/resolution400.ps is a short
example, /usr/share/texmf/dvips/misc/crops.pro is a bit longer.
There
Jonas Meurer [EMAIL PROTECTED] writes:
it produces at least a bloated passwd/group/shadow file. This is reason
enough to consider possible solutions.
You're worried about disk consumption?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Wed, Oct 26, 2005 at 11:07:11AM -0700, Thomas Bushnell BSG wrote:
Moreover, the consequences of getting the one wrong are that you
delete the sysadmin's changes.
It can be worse.
If you create a directory for working files which you remove on package
removal (with rmdir), but which contains
On 27-Oct-05, 07:53 (CDT), Steve Langasek [EMAIL PROTECTED] wrote:
Nah, the biggest hit isn't disk space, it's NSS lookup times from having to
do a linear search through a flat-file /etc/passwd and /etc/shadow. Well,
thank God no one uses pam_pwdb anymore, at least...
I'd be willing to bet
Florian Weimer [EMAIL PROTECTED] writes:
There are people in this world who can read and program PostScript.
Sure, and it's the preferred form of modifcation for removing
ink-wasting background images from Powerpoint presentations, but: This
is not the kind of modifcation I'm talking about.
On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
? Have you looked at the code I added to the developer's reference _at_all_?
Yes. Have you read adduser docs _at_all_?
Creating system users needs to cope with the fact that users might have
greated them
Frankly, I do not see any advantage in your dh_user idea.
I can see one...even if I follow this discussion quite loosely:
Currently, all packages needing to add a system user do it their own
way. Some do it very carefully with nice error checking and stuff, by
using adduser, etc.
Some others
* Florian Weimer [EMAIL PROTECTED] [051025 13:51]:
* Steve Langasek:
Frank Lichtenheld has already posted an announcement[4] detailing the
release team's plans for the question of non-DFSG documentation in main.
Just to clarify, is technical documentation that is only available in
On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
Creating system users needs to cope with the fact that users might have
greated them before hand.
adduser copes with that. If a system user
On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
Thus, in most cases, a single call to adduser is all that's needed to
create a system user in postinst.
I have yet to see a package that just
On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Peńa wrote:
That really depends on the daemon itself don't you think? There's a number of
daemons that don't create any file at all or, if they do, are created
only on a given directory which is removed on purge. In these
On 10/26/05, Gabor Gombas [EMAIL PROTECTED] wrote:
On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Peńa
wrote:
That really depends on the daemon itself don't you think? There's a number
of
daemons that don't create any file at all or, if they do, are created
only
On Wed, Oct 26, 2005 at 02:00:17PM +0200, Olaf van der Spek wrote:
Removing the user is 'fine', it's the reusing that's the issue. But
isn't that your own fault if you choose to reuse numbers?
If a package's postrm removes the user, and the next package's postinst
just calls adduser, then the
On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote:
If a package's postrm removes the user, and the next package's postinst
just calls adduser, then the admin have no control over the reusing.
If you want to allow automatic user/group removal, then adduser should
be extended to
On Wed, Oct 26, 2005 at 08:20:02AM -0400, sean finney wrote:
On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote:
If a package's postrm removes the user, and the next package's postinst
just calls adduser, then the admin have no control over the reusing.
If you want to allow
hey steve,
On Wed, Oct 26, 2005 at 05:29:46AM -0700, Steve Langasek wrote:
In the general case, I can think of two reasons to remove users (but
leave the ids reserved): namespace pollution, and user lookup performance
when using flatfile /etc/passwd. Neither of these is particularly relevant
* Marc Haber ([EMAIL PROTECTED]) wrote:
On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
Some remove the user
(and fail to check if it was created by the postinst/preinst and not by the
alocal admin),
Removing the user is a general bug, IMO. They
On Wed, Oct 26, 2005 at 12:16:43PM +0200, Marc Haber wrote:
On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
Please explain, the code only changes /etc/{passwd,shadow,group}. Where's the
RC bug?
If I generate user foo and give it some attributes,
On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote:
On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a
wrote:
That really depends on the daemon itself don't you think? There's a number
of
daemons that don't create any file at all or, if they do, are
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote:
On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote:
On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a
wrote:
That really depends on the daemon itself don't you think? There's a number
of
daemons
On Wed, Oct 26, 2005 at 03:50:36PM +0200, Javier Fernández-Sanguino Peńa wrote:
Wrong. That is only true in the chown() case. Which is not a sensible thing
to do. Daemons should be able to read their configuration files but they
usually *don't* need to *write* them, so they should *not* own
* sean finney ([EMAIL PROTECTED]) [051026 14:20]:
On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote:
If a package's postrm removes the user, and the next package's postinst
just calls adduser, then the admin have no control over the reusing.
If you want to allow automatic
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes:
Removing system users on package purge is widely regarded a bug since
one cannot guarantee that the local admin hasn't used the account for
other things as well. Additionally, removing the system user on
package purge might leave
Gabor Gombas [EMAIL PROTECTED] writes:
IMHO you can safely remove an user/group _only_ if you have made sure
there are no files owned by that uid/group left on any filesystems (and
checking that may be tricky if the system uses ACLs, for example).
Any filesystems here must include removable
On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote:
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote:
On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote:
On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a
wrote:
That really depends on
Stephen Frost [EMAIL PROTECTED] writes:
I disagree with the idea that removing a user is a bug. If the user was
added by the package, and the package is being purged, and there's a
reasonable expectation that it wasn't used outside of the package's use
of it then I think it's probably safe
On Wed, Oct 26, 2005 at 05:24:46PM +0200, Gabor Gombas wrote:
On Wed, Oct 26, 2005 at 03:50:36PM +0200, Javier Fernández-Sanguino Pe?a
wrote:
Wrong. That is only true in the chown() case. Which is not a sensible thing
to do. Daemons should be able to read their configuration files but
On Wed, Oct 26, 2005 at 05:39:45PM +0200, Andreas Barth wrote:
i don't think removing and reusing users is a good idea in practice.
what harm would there be in simply leaving the user account on the
system permenantly, with maybe locking the account and setting the
shell to /bin/false?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I disagree with the idea that removing a user is a bug. If the user was
added by the package, and the package is being purged, and there's a
reasonable expectation that it wasn't used outside of the
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* sean finney ([EMAIL PROTECTED]) [051026 14:20]:
i don't think removing and reusing users is a good idea in practice.
what harm would there be in simply leaving the user account on the
system permenantly, with maybe locking the account and setting
On Wed, Oct 26, 2005 at 08:44:12AM -0700, Thomas Bushnell BSG wrote:
One cannot guarantee that the local admin hasn't used the account for
other things as well.
Please read.
We cannot guarantee that an admin fiddles with binaries in /usr/bin/ (as
opposed to /usr/local/bin) either. That
* Gabor Gombas ([EMAIL PROTECTED]) [051026 18:03]:
On Wed, Oct 26, 2005 at 05:39:45PM +0200, Andreas Barth wrote:
i don't think removing and reusing users is a good idea in practice.
what harm would there be in simply leaving the user account on the
system permenantly, with maybe
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]:
We can provide a sensible default for system users' removals that copes with
most situations and leave a door open (through debconf) to sysadmins that
want to fiddle with system users.
I really want to warn to try to be too
Andreas Barth wrote:
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]:
We can provide a sensible default for system users' removals that
copes with most situations and leave a door open (through debconf)
to sysadmins that want to fiddle with system users.
I really want to
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:28]:
Andreas Barth wrote:
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]:
We can provide a sensible default for system users' removals that
copes with most situations and leave a door open (through debconf)
to sysadmins that
Andreas Barth wrote:
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:28]:
Andreas Barth wrote:
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]:
We can provide a sensible default for system users' removals that
copes with most situations and leave a door open (through
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]:
in my workstation I try out a new package (for scientfic computing, a
game for Lucas, a new development package) at least once each two days,
and a lot of times they come with their libs and their daemons -- and
their users. So I see
Andreas Barth wrote:
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]:
in my workstation I try out a new package (for scientfic computing, a
game for Lucas, a new development package) at least once each two days,
and a lot of times they come with their libs and their daemons -- and
their
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:48]:
Andreas Barth wrote:
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]:
in my workstation I try out a new package (for scientfic computing, a
game for Lucas, a new development package) at least once each two days,
and a lot of times
ke, 2005-10-26 kello 14:30 -0300, Humberto Massa kirjoitti:
Problem being, if daemons don't remove their (supposedly exclusive-use)
accounts, you can end in two years with 100 unnecessary accounts in a
workstation.
It would certainly be good if we had a system for marking accounts as
unused by
Hello everyone,
following all the discussion about when to add or remove users/groups
and when to do this, i must that maybe some work is done (not using the
standard adduser commands but almost).
I package libuser (from RH). From the Description:
The libuser library
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes:
On Wed, Oct 26, 2005 at 08:44:12AM -0700, Thomas Bushnell BSG wrote:
One cannot guarantee that the local admin hasn't used the account for
other things as well.
Please read.
We cannot guarantee that an admin fiddles with binaries
Humberto Massa [EMAIL PROTECTED] writes:
Problem being, if daemons don't remove their (supposedly exclusive-use)
accounts, you can end in two years with 100 unnecessary accounts in a
workstation.
And what bad results does this produce?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Stephen Frost [EMAIL PROTECTED] writes:
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I disagree with the idea that removing a user is a bug. If the user was
added by the package, and the package is being purged, and there's a
reasonable
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Humberto Massa [EMAIL PROTECTED] writes:
Problem being, if daemons don't remove their (supposedly exclusive-use)
accounts, you can end in two years with 100 unnecessary accounts in a
workstation.
And what bad results does this produce?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
By knowing what the package uses the user for. This is somewhat akin to
the PostgreSQL package's question do you want your data files to be
purged upon package removal, or the fact that the default
Stephen Frost [EMAIL PROTECTED] writes:
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
By knowing what the package uses the user for. This is somewhat akin to
the PostgreSQL package's question do you want your data files to be
purged upon package
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Same way you know that the system administrator hasn't modified a file
in /usr/bin.
Um, I know that by comparing the contents against a known-true
version. How do I detect whether the system
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Same way you know that the system administrator hasn't modified a file
in /usr/bin.
Um, I know that by comparing the contents against a
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
This is just patently false, as has been pointed out elsewhere. What
security hole, exactly, is created by orphaning a file?
Well, if some process (maybe within the package) creates a private
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:46]:
Additionally, this is *not* a problem with the orphaning of the file,
it's a problem with the reuse of a previously-used uid. I could see
adding a system to track previously-used uids and not reusing them. I
don't believe using passwd for
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:46]:
Additionally, this is *not* a problem with the orphaning of the file,
it's a problem with the reuse of a previously-used uid. I could see
adding a system to track previously-used uids and not
On Wed, Oct 26, 2005 at 02:58:15PM -0400, Stephen Frost wrote:
Leaving around unused accounts is plainly wrong too, and also a
iyho.
potential security risk. If we're going to try to push for a broad
change in how this is handled then let's do it the *right* way by
or, how about we not push
On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote:
On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote:
What about log files with sensitive content?
Non-issue, as I said in the end of my post, those should be removed
on purge.
The log files that are created by the default
* sean finney ([EMAIL PROTECTED]) wrote:
On Wed, Oct 26, 2005 at 02:58:15PM -0400, Stephen Frost wrote:
Leaving around unused accounts is plainly wrong too, and also a
iyho.
Duh? I ain't humble tho. :)
potential security risk. If we're going to try to push for a broad
change in how
* Don Armstrong ([EMAIL PROTECTED]) wrote:
On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote:
On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote:
What about log files with sensitive content?
Non-issue, as I said in the end of my post, those should be removed
on
Stephen Frost wrote:
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
This is just patently false, as has been pointed out elsewhere.
What
security hole, exactly, is created by orphaning a file?
Well, if some process (maybe within the package)
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:58]:
Leaving around unused accounts is plainly wrong too, and also a
potential security risk.
I'm certain you can proof this.
If we're going to try to push for a broad
change in how this is handled then let's do it the *right* way by
creating
Stephen Frost [EMAIL PROTECTED] writes:
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Same way you know that the system administrator hasn't modified a file
in /usr/bin.
Um, I know that by comparing the contents against a known-true
version.
Stephen Frost [EMAIL PROTECTED] writes:
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
This is just patently false, as has been pointed out elsewhere. What
security hole, exactly, is created by orphaning a file?
Well, if some process
Stephen Frost [EMAIL PROTECTED] writes:
Leaving around unused accounts is plainly wrong too, and also a
potential security risk.
Can you outline the risk please?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Stephen Frost [EMAIL PROTECTED] writes:
Have we actually got a specific case of this happening and there being a
real security threat from it? Seems like an aweful lot of hand-waving
and concern for a possible scenario that doesn't seem to have actually
happened much (if it all, so far all
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Leaving around unused accounts is plainly wrong too, and also a
potential security risk.
Can you outline the risk please?
Sure. Locking accounts isn't necessairly perfect. Checking that an
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
We aren't talking about log files created by the package, but by the
sysadmin.
What if the sysadmin has taken the sensitive log and squirreled it
away, saving it for future reference? Is that no longer a supported
thing?
One would hope
On Wed, Oct 26, 2005 at 06:29:57PM +0200, Andreas Barth wrote:
Problem being, if daemons don't remove their (supposedly exclusive-use)
accounts, you can end in two years with 100 unnecessary accounts in a
workstation.
How many daemon packages do you install in two years? I even doubt that
This one time, at band camp, Javier Fernández-Sanguino Peña said:
On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
Creating system users needs to cope with the fact that users might
have
Stephen Frost [EMAIL PROTECTED] writes:
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Leaving around unused accounts is plainly wrong too, and also a
potential security risk.
Can you outline the risk please?
Sure. Locking accounts isn't
1 - 100 of 140 matches
Mail list logo
