Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst. However, most
> postinsts wrap the call to adduser with a check for whether the
> account already exists, so it would not be called without an
> update to every pr
(culled cc list of a few people I know read -devel)
Roger Leigh wrote:
> Given the need to consider unlocking as well as locking, I'm not sure
> it's worth adding special support to deluser: the typical logic used
> to create the user will be insufficient to unlock, so it's no less
> the effort to
On Thu, 31 Mar 2011 09:23:33 +0100, Lars Wirzenius wrote:
>Would a debhelper tool to create/remove system users be useful? I
>suspect there's only relatively few packages that do that, so perhaps
>not.
I had that discussion years ago with Joey and his comments were the
cause that I submitted patc
(Cc to the relevant bug added.)
On ma, 2011-04-11 at 14:05 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("Re: System users: removing them"):
> > Thus, I propose to change 9.2.2 "UID and GID classes", the paragraph on
> > uids in the range 100-999, to add t
Lars Wirzenius writes ("Re: System users: removing them"):
> Thus, I propose to change 9.2.2 "UID and GID classes", the paragraph on
> uids in the range 100-999, to add the following sentence to the end of
> the paragraph:
>
> Packages must not remov
Adding a copy to the bug report.
Everyone please Cc 621...@bugs.debian.org if replying to this subhtread.
Thanks.
On la, 2011-04-09 at 10:14 +0100, Roger Leigh wrote:
> On Sat, Apr 09, 2011 at 09:44:28AM +0100, Lars Wirzenius wrote:
> > Package: debian-policy
> > Version: 3.9.2.0
> >
> > thanks
On Sat, Apr 09, 2011 at 09:44:28AM +0100, Lars Wirzenius wrote:
> Package: debian-policy
> Version: 3.9.2.0
>
> thanks
>
> Background for the policy list: see thread starting at
> http://lists.debian.org/debian-devel/2011/03/msg01174.html
> and continuing in April at
> http://lists.debian.org/deb
Package: debian-policy
Version: 3.9.2.0
thanks
Background for the policy list: see thread starting at
http://lists.debian.org/debian-devel/2011/03/msg01174.html
and continuing in April at
http://lists.debian.org/debian-devel/2011/04/msg00210.html
On ma, 2011-04-04 at 21:09 +0100, Lars Wirzenius
Tollef Fog Heen writes:
> - Most or all system accounts are locked and unable to be used for
> login. Perhaps policy should say that user accounts belonging to a
> package must be locked when the package is removed?
Speaking of that, fixing Bug#274229 and the merged bugs for wheezy would
su
]] Lars Wirzenius
Hi,
| I think this would be a good point to have a discussion and set policy
| on how to deal with this. The policy manual seems to currently be silent
| about removing users created by the package at installation time.
|
| * We can decide that packages may not remove th
On to, 2011-03-31 at 14:18 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("System users: removing them"):
> > The easy solution for this would be to never remove the user, but that's
> > also not so clear.
>
> To remove a user and reclaim the uid is a difficult business.
This is true in the g
On Thursday, March 31, 2011 04:23:33 AM Lars Wirzenius wrote:
> We have some packages that require a dedicated user to be created, and
> calling "adduser --system" in postinst does that. However, it is not
> always clear whether such users should be removed when the package is
> removed.
>
>
Lars Wirzenius writes ("System users: removing them"):
> The easy solution for this would be to never remove the user, but that's
> also not so clear.
To remove a user and reclaim the uid is a difficult business.
> * Extra accounts are just wasteful, and may cause some confusion.
> *
Hi,
On Sat, 15.11.2008 at 08:49:12 +0100, Vincent Bernat wrote:
> On some systems like OpenBSD, all those users are starting with
> underscore to avoid collision with real users. On Debian, I have never
> seen this, even for packages that comes from OpenBSD (like openntpd
> which
On Sun, Nov 30, 2008 at 04:29:28PM +0100, Petter Reinholdtsen wrote:
> [Vincent Bernat]
> >> That is nice. We will be able to get reasonable output under ps
> >> command for exim4 too.
> >
> > You are right. Too long usernames are displayed numerically.
>
> ps, top and wtmp/utmp (ie w,last, etc)
[Vincent Bernat]
>> That is nice. We will be able to get reasonable output under ps
>> command for exim4 too.
>
> You are right. Too long usernames are displayed numerically.
ps, top and wtmp/utmp (ie w,last, etc) have user name limits. For ps
and top, it seem to be the POSIX limit of 8 characte
Vincent Bernat wrote:
> Here is the list of package that name the user with the name of the
> source package:
- vdr:vdr
Tobias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On 2008-11-21 08:18 +0100, Vincent Bernat wrote:
> Here is the list of package that name the user with the name of the
> source package:
> [...]
> - zabbix: zabbix
- postfix: postfix
- dictd: dictd
> And the ones that uses a prefix:
> - exim4: Debian-exim
> - lldpd: _lldpd
- xf
OoO En ce doux début de matinée du vendredi 21 novembre 2008, vers
08:18, je disais:
> And the ones that uses a prefix:
> - exim4: Debian-exim
> - lldpd: _lldpd
I have missed console-log and Debian-console-log. I suppose that this is
because it is arch-indep.
--
BOFH excuse #433:
error: on
OoO En ce milieu de nuit étoilée du vendredi 21 novembre 2008, vers
03:19, Raphael Geissert <[EMAIL PROTECTED]> disait :
>> Is there some way to easily retrieve all postinst scripts to check how
>> adduser is called?
> Yup, take a look at lintian.debian.org's lab in gluck.
> It only conta
Vincent Bernat wrote:
[...]
>
> Is there some way to easily retrieve all postinst scripts to check how
> adduser is called?
Yup, take a look at lintian.debian.org's lab in gluck.
It only contains the maintainer scripts of main/i386, though.
Cheers,
Raphael Geissert
--
To UNSUBSCRIBE, email
This one time, at band camp, Vincent Bernat said:
> Is there some way to easily retrieve all postinst scripts to check how
> adduser is called?
adduser largely exists to be a policy compliant framework for maintainer
script user manipulation. If policy changes, adduser will too. The
major pain
OoO En ce doux début de matinée du samedi 15 novembre 2008, vers 08:49,
je disais:
> ,[ http://wiki.debian.org/AccountHandlingInMaintainerScripts ]
> | A collision free way to name system accounts should really be mentioned
> | in Debian policy to stop this uncontrolled growth of different m
OoO En cette fin de matinée radieuse du dimanche 16 novembre 2008, vers
11:46, Osamu Aoki <[EMAIL PROTECTED]> disait :
>> On some systems like OpenBSD, all those users are starting with
>> underscore to avoid collision with real users. On Debian, I have never
>> seen this, even for p
On 2008-11-16 11:41 +0100, Vincent Bernat wrote:
> Unfortunately, by default, NAME_REGEX does not allow the use of
> underscore. The user needs to be created with --force-badname.
Why is that unfortunate? IMO it is good if system users have "bad"
names since that makes clashes with name
Vincent Bernat wrote:
>>> On some systems like OpenBSD, all those users are starting with
>>> underscore to avoid collision with real users. On Debian, I have never
>>> seen this, even for packages that comes from OpenBSD (like openntpd
>>> which uses "ntpd"). Is there some drawback
On Sat, Nov 15, 2008 at 08:49:12AM +0100, Vincent Bernat wrote:
> Hi!
>
> ,[ http://wiki.debian.org/AccountHandlingInMaintainerScripts ]
> | A collision free way to name system accounts should really be mentioned
> | in Debian policy to stop this uncontrolled growth of different methods.
> `-
OoO En ce début d'après-midi nuageux du samedi 15 novembre 2008, vers
14:02, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> disait :
>> On some systems like OpenBSD, all those users are starting with
>> underscore to avoid collision with real users. On Debian, I have never
>> seen
OoO En cette matinée pluvieuse du samedi 15 novembre 2008, vers 10:16,
Thomas Viehmann <[EMAIL PROTECTED]> disait :
>> On some systems like OpenBSD, all those users are starting with
>> underscore to avoid collision with real users. On Debian, I have never
>> seen this, even for pac
On Sat, 15 Nov 2008, Vincent Bernat wrote:
> On some systems like OpenBSD, all those users are starting with
> underscore to avoid collision with real users. On Debian, I have never
> seen this, even for packages that comes from OpenBSD (like openntpd
> which uses "ntpd"). Is there
Hi,
Vincent Bernat wrote:
> On some systems like OpenBSD, all those users are starting with
> underscore to avoid collision with real users. On Debian, I have never
> seen this, even for packages that comes from OpenBSD (like openntpd
> which uses "ntpd"). Is there some drawbacks w
Uwe Hermann <[EMAIL PROTECTED]> writes:
> On Fri, May 05, 2006 at 11:12:35AM +0300, Jari Aalto wrote:
>> > The rest of the system accounts are happily running with /bin/false
>>
>> There is now /bin/nologin which is more secure
>
> I think you mean /usr/sbin/nologin, right? Please define "more sec
On 8 May 2006, Marc Haber outgrape:
> On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto
> <[EMAIL PROTECTED]>
> wrote:
>> Richard A Nelson <[EMAIL PROTECTED]> writes:
>>> On Wed, 3 May 2006, Colin Watson wrote:
>>> The rest of the system accounts are happily running with
>>> /bin/false
>>
>> There is
On Mon, May 08, 2006 at 01:36:14AM +0200, Uwe Hermann wrote:
>
> Or does such a thing already exist?
Not that I know of, such a report might be interesting...
Regards
Javier
signature.asc
Description: Digital signature
On Mon, May 08, 2006 at 09:04:35AM +0200, Marc Haber wrote:
> On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto <[EMAIL PROTECTED]>
> wrote:
> >Richard A Nelson <[EMAIL PROTECTED]> writes:
> >> On Wed, 3 May 2006, Colin Watson wrote:
> >> The rest of the system accounts are happily running with /bin/f
On Mon, May 08, 2006 at 12:47:53PM +0100, Thiemo Seufer wrote:
> So you expect systems to become exploitable by mounting /usr as noexec
> when they provide some /usr/bin/foo shell?
Not actually "expect", but I would not be _that_ suprised. Most programs
that care about the login shell tend to run
Gabor Gombas wrote:
> On Mon, May 08, 2006 at 11:53:15AM +0100, Thiemo Seufer wrote:
>
> > Such a binary is completely broken, and it would fail in a similiar way
> > for any sort of file it has no execute permission for, not only for
> > $SHELL.
>
> Sure, but that does not change the fact that i
On Mon, May 08, 2006 at 11:53:15AM +0100, Thiemo Seufer wrote:
> Such a binary is completely broken, and it would fail in a similiar way
> for any sort of file it has no execute permission for, not only for
> $SHELL.
Sure, but that does not change the fact that it is a failure path that
is usuall
Gabor Gombas wrote:
> On Mon, May 08, 2006 at 10:00:42AM +0100, Thiemo Seufer wrote:
>
> > > You can surely explain why /bin/nologin is more secure than
> > > /bin/false. I'm eager to learn.
> >
> > I am curious why any of both would be more secure than /dev/null, a
> > place which makes it hard
On Mon, May 08, 2006 at 10:00:42AM +0100, Thiemo Seufer wrote:
> > You can surely explain why /bin/nologin is more secure than
> > /bin/false. I'm eager to learn.
>
> I am curious why any of both would be more secure than /dev/null, a
> place which makes it hard to smuggle an infected binary into
Marc Haber wrote:
> On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto <[EMAIL PROTECTED]>
> wrote:
> >Richard A Nelson <[EMAIL PROTECTED]> writes:
> >> On Wed, 3 May 2006, Colin Watson wrote:
> >> The rest of the system accounts are happily running with /bin/false
> >
> >There is now /bin/nologin whic
On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto <[EMAIL PROTECTED]>
wrote:
>Richard A Nelson <[EMAIL PROTECTED]> writes:
>> On Wed, 3 May 2006, Colin Watson wrote:
>> The rest of the system accounts are happily running with /bin/false
>
>There is now /bin/nologin which is more secure
You can surely
Hi,
thanks for the pointers, I'll read the old discussions ASAP...
On Wed, May 03, 2006 at 01:48:33PM +0200, Javier Fernández-Sanguino Peña wrote:
> AFAIK, this is already being done in Red Hat, SuSE, FreeBSD and OpenBSD for
> many system users.
I'm currently installing tons of distributions on
Hi,
On Fri, May 05, 2006 at 11:12:35AM +0300, Jari Aalto wrote:
> > The rest of the system accounts are happily running with /bin/false
>
> There is now /bin/nologin which is more secure
I think you mean /usr/sbin/nologin, right? Please define "more secure"
in this context.
Uwe.
--
Uwe Herman
Richard A Nelson <[EMAIL PROTECTED]> writes:
> On Wed, 3 May 2006, Colin Watson wrote:
>
>
> The rest of the system accounts are happily running with /bin/false
>
There is now /bin/nologin which is more secure
Jari
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe".
On Wed, May 03, 2006 at 01:48:33PM +0200, Javier Fernández-Sanguino Peña wrote:
>
> In any case, you could use noshell (already available in Debian) or nologin
> (see #298782) instead of /bin/false.
nologin is now distributed with login.
I've closed the ITP.
Kind Regards,
--
Nekral
--
To UNS
On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote:
> Security-wise it's probably a good idea to give as few users as possible
> a valid shell, all others should get /bin/false, right?
AFAIK, this is already being done in Red Hat, SuSE, FreeBSD and OpenBSD for
many system users. And is th
On May 03, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> I get tons of warnings like this when I run tiger(8):
Tools like this need to generate lots of warnings or people may start
thinking that they are useless...
> Security-wise it's probably a good idea to give as few users as possible
> a valid sh
On Wed, 3 May 2006, Colin Watson wrote:
On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote:
this may be a dumb question, but I really wonder if there's a policy
(which I obviously haven't found) about which system users should get
a valid shell and which shouldn't.
Yeah, I had the sa
On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote:
> this may be a dumb question, but I really wonder if there's a policy
> (which I obviously haven't found) about which system users should get
> a valid shell and which shouldn't.
This is bug #330882, and is basically because I'm excepti
On Mon, 10 Apr 2006, Noah Meyerhans wrote:
Really? I get spam addressed to ftp, cyrus (the Cyrus IMAP system),
postfix, apache, daemon, etc etc all the time. Those are very common
user names, and (even better for the spammers) their mail is typically
aliased to a group of people. They're proba
On Mon, Apr 10, 2006 at 11:43:53AM -0700, Stephen Samuel wrote:
> Also: in my experience, I've rarely received spam for system users other
> than postmaster and webmaster -- and those are probably due to DNS
> registrations and the like.
Really? I get spam addressed to ftp, cyrus (the Cyrus IMA
I run a hybred Red-Hat/Debian system, (started on Red-Hat), so I
definitely have users in the 500-1000
range.
I know that Solaris systems used to start at uid=100.
In other words, dumping email just based on the UID seems like a
dangerous thing if you want to run in a mixed environment.
If a
On Mon, Apr 10, 2006 at 11:16:06AM +0200, Wouter Verhelst wrote:
> * System users on a Debian system are created with the --system
> argument. On reading the manpage, these users are called "system
> users", not "Debian system users"; so non-Debian software could very
> well be using that by
Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 09, 2006 at 07:53:44PM +0200, Andreas Metzler wrote:
>> Ron Johnson <[EMAIL PROTECTED]> wrote:
>>> On Sun, 2006-04-09 at 12:25 +0200, Andreas Metzler wrote:
>> [...]
And now I am wondering whether this will break existing packages.
>>>
On Sun, Apr 09, 2006 at 07:53:44PM +0200, Andreas Metzler wrote:
> Ron Johnson <[EMAIL PROTECTED]> wrote:
> > On Sun, 2006-04-09 at 12:25 +0200, Andreas Metzler wrote:
> [...]
> >> And now I am wondering whether this will break existing packages.
>
> > Maybe not *packages*, but possibly non-Debian
Re: Andreas Metzler 2006-04-09 <[EMAIL PROTECTED]>
> > I'm not aware of any package inserting its system users into
> > /etc/aliases, and in fact, my sid chroot doesn't even have that file.
>
> They shouldn't, unless they want to receive mail for the system-user
> account.
If they _don't_ want to
On Sun, 2006-04-09 at 19:53 +0200, Andreas Metzler wrote:
> Ron Johnson <[EMAIL PROTECTED]> wrote:
> > On Sun, 2006-04-09 at 12:25 +0200, Andreas Metzler wrote:
> [...]
> >> And now I am wondering whether this will break existing packages.
>
> > Maybe not *packages*, but possibly non-Debian softwa
Christoph Berg <[EMAIL PROTECTED]> wrote:
> Re: Andreas Metzler 2006-04-09 <[EMAIL PROTECTED]>
>> #1 sane packages redirect mail via /etc/aliases
>> #2 un-aliased mail to systemusers (e.g. spam) is not accepted and
>> dumped into /var/mail/systemuser but rejected immediately (at SMTP
>> time).
> I
Ron Johnson <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-04-09 at 12:25 +0200, Andreas Metzler wrote:
[...]
>> And now I am wondering whether this will break existing packages.
> Maybe not *packages*, but possibly non-Debian software.
non-Debian software, running in the Debian system-user id range?
Re: Andreas Metzler 2006-04-09 <[EMAIL PROTECTED]>
> #1 sane packages redirect mail via /etc/aliases
> #2 un-aliased mail to systemusers (e.g. spam) is not accepted and
> dumped into /var/mail/systemuser but rejected immediately (at SMTP
> time).
I'm not aware of any package inserting its system u
On Sun, 2006-04-09 at 12:25 +0200, Andreas Metzler wrote:
> Sam Morris <[EMAIL PROTECTED]> wrote:
> > Andreas Metzler wrote:
> >> Hello,
> >> system users like proxy, sshd or identd usually do not receive any
> >> mail at all. And system-users that _do_ receive mail are usually
> >> redirected to a
Sam Morris <[EMAIL PROTECTED]> wrote:
> Andreas Metzler wrote:
>> Hello,
>> system users like proxy, sshd or identd usually do not receive any
>> mail at all. And system-users that _do_ receive mail are usually
>> redirected to a real user by /etc/aliases.
>> I do wonder whether it would be safe t
Andreas Metzler wrote:
Hello,
system users like proxy, sshd or identd usually do not receive any
mail at all. And system-users that _do_ receive mail are usually
redirected to a real user by /etc/aliases.
I do wonder whether it would be safe to reject any mail for
system-accounts (uid <1000 || u
64 matches
Mail list logo
