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, a
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 con
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
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-exi
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
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 Machines
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
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
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.
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
> >attem
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
>upgradi
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
> "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
>> (s
* 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.
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 Powerpoi
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, /usr/share/tex
* 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 m
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
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 b
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 contain
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 [EM
* 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.
>
> The
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/s
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 a
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 d
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 th
* 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.
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 ins
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 e
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 t
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
* 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 document
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 thei
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
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 be
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
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 /etc
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 mi
> "Javier" == Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes:
>> Thus, in most cases, a single call to adduser is all that's
>> needed to create a system user in postinst.
Javier> I have yet to see a package that "just" calls
Javier> adduser. Some remove the user (
This one time, at band camp, Thomas Bushnell BSG said:
> Stephen Gran <[EMAIL PROTECTED]> writes:
>
> > Many authentiaction systems do not use pam or shadow authentication.
> > That's the point of the counter argument.
>
> So how does removing the line from the password file suddenly change
> t
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 syste
Stephen Gran <[EMAIL PROTECTED]> writes:
> Many authentiaction systems do not use pam or shadow authentication.
> That's the point of the counter argument.
So how does removing the line from the password file suddenly change
things?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
This one time, at band camp, Thomas Bushnell BSG said:
> 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 sec
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. Lock
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 mig
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 dou
* 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 hop
* 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
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
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:
> * 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
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-t
* 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
> creati
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) cr
* 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
>
* 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
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 def
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 pu
* 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 n
* 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 fo
* 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 priv
* 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 aga
* 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]> 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
>> > pur
* 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 d
* 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
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
>> >
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
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 fiddle
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 impl
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
* 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 o
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 us
* 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 t
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 debco
* 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 sy
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
* 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
* 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 m
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. Th
* 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 s
* 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 outsid
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/fa
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 b
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 s
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
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 remov
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 lea
* 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 auto
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
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
>> >
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,
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 attr
* 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
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 relevan
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 all
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
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 t
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 create
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 ca
1 - 100 of 139 matches
Mail list logo
