/GIDs in order to further partition
daemons from one another."
Users have to have *some* gid (you can add a non-existent one manually
in the passwd database, but no tools will allow it). Whether is
"nogroup" or "daemon" is irrelevant, security-wise; only an un
On Wed, 06 Jul 2022 15:21:03 -0400, Matt Barry
wrote:
>On Mon, 2022-07-04 at 09:12 +0200, Marc Haber wrote:
>> adduser has been putting newly created 'dynamically allocated system
>> users' (adduser --system) into the nogroup group. It is also
>> documented to
Hi!
On Mon, 2022-07-04 at 09:12 +0200, Marc Haber wrote:
> Hi,
>
> adduser has been putting newly created 'dynamically allocated system
> users' (adduser --system) into the nogroup group. It is also
> documented to do so. There is an ancient bug report complaining about
Hi,
adduser has been putting newly created 'dynamically allocated system
users' (adduser --system) into the nogroup group. It is also
documented to do so. There is an ancient bug report complaining about
this, and I think this is a valid complaint. However,
/usr/share/doc/base-passwd
way forward would be to get that adduser patch merged,
>> then keep promoting the underscore usage, and possibly try to switch
>> existing users to use that.
>
> ISTM to me we have a consensus, at least, that new packages with system
> users should use the underscore prefix conventi
s).
>>
>> I would like to see this adopted, but I am not sure how that solves the
>> namespace problem.
>>
>
> Well the point is that the need to create system users can be avoided
> entirely by running services using only dynamic UIDs.
>
> --
> Regards,
> Scott Leggett.
> Well the point is that the need to create system users can be avoided
> entirely by running services using only dynamic UIDs.
Except that some services rely on Database granted access ...
Cheers
Frederic
On 2019-02-10.09:08, Ondřej Surý wrote:
> This is fairly easy to be scripted (same as with tmpfiles).
>
> I would like to see this adopted, but I am not sure how that solves the
> namespace problem.
>
Well the point is that the need to create system users can be avoided
enti
This is fairly easy to be scripted (same as with tmpfiles).
I would like to see this adopted, but I am not sure how that solves the
namespace problem.
Ondrej
--
Ondřej Surý
> On 10 Feb 2019, at 05:45, Scott Leggett wrote:
>
>> On 2019-02-09.13:10, Philipp Kern wrote:
>> How do others deal wi
On 2019-02-09.13:10, Philipp Kern wrote:
> How do others deal with this problem? Could someone think of a viable
> approach on how to approach this from a policy side?
systemd has an elegant solution for this problem, which I would like to
see more widely adopted:
http://0pointer.net/blog/dynamic
On Feb 09, Sean Whitton wrote:
> ISTM to me we have a consensus, at least, that new packages with system
> users should use the underscore prefix convention. There isn't a
> consensus on what to do about old packages, but Policy can be written in
> such a way to refer only to
Sam Hartman writes:
> I'd like to support the _user convention as well.
> It works well as packages move around between distributions and things
> get upstreamed.
Agreed. I think we should just write this up as the recommended approach
for all new system users in Policy.
rscore usage, and possibly try to switch
> existing users to use that.
ISTM to me we have a consensus, at least, that new packages with system
users should use the underscore prefix convention. There isn't a
consensus on what to do about old packages, but Policy can be written in
such a wa
I'd like to support the _user convention as well.
It works well as packages move around between distributions and things
get upstreamed.
On Sat, Feb 09, 2019 at 01:34:41PM +0100, Vincent Bernat wrote:
> This is a recurring topic. See:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248809
in addition to this -policy bug there is also #399028
"developers-reference: best practices to create and delete system
accounts" which sugg
d risk of
> collisions with system users as created by Debian packages.
Yes. :(
> Of course it is easy to precompile a basic list to ban users from taking
> names like postfix, bind, or sshd. But it will never be exhaustive, packages
> are still free to come up with random names and users are f
On Sat, 09 Feb 2019 at 13:10:27 +0100, Philipp Kern wrote:
> Obviously an increasing number of accounts leads to a much increased risk of
> collisions with system users as created by Debian packages.
This topic comes up every so often and doesn't ever seem to come to a
concl
❦ 9 février 2019 13:10 +01, Philipp Kern :
> Some core packages recently adding system users resorted to names like
> systemd-$daemon and _apt, which both address my concerns - as you can
> come up with simple rules like "no user might include [-_] in their
> username". On
On 2019-02-09 13:10, Philipp Kern wrote:
> How do others deal with this problem?
In my company, we use leading underscore for all non-human
accounts. Human accounts get lower-case ASCII letters only.
Also, we use the same uid/gid for the same human user on all
machines (1000 + something unique, e
Hi,
at work we have a large fleet of Debian machines, but also more than
200k user accounts with no reuse and somewhat painful rename
experiences. Obviously an increasing number of accounts leads to a much
increased risk of collisions with system users as created by Debian
packages.
Of
On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.
Yes, that would be the way to go for adduser --system
> However, most postinsts wrap the call to adduser with a check f
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
>I'm currently using this logic (in postinst)
>
> # Create dedicated sbuild user
> if ! getent passwd sbuild > /dev/null; then
> adduser --system --quiet --home /var/lib/sbuild --no-create-home \
> --shell
On Sat, 30 Jun 2012 14:36:47 +0100, Roger Leigh
wrote:
>On Sat, Jun 30, 2012 at 02:12:45PM +0100, Simon McVittie wrote:
>> [in the preinst]
>> > -usermod -U -e '' quake-server
>> > +if [ -f /etc/shadow ]; then
>> > + usermod -U -e '' quake-server
>> > +else
>> > + usermod -U
need a script
> (or dpkg-maintscript-helper subcommand) that locks and unlocks system
> users, in which we can make changes like this once and have them affect
> every relevant package, rather than individually patching every
> maintainer script.
>
> Roger: does the change below
ng
Policy bug #621833 (where it was originally suggested by Roger Leigh),
so this potentially affects quite a few packages.
Stephan's proposed patch (below) makes me think we really need a script
(or dpkg-maintscript-helper subcommand) that locks and unlocks system
users, in which we can make cha
On Mon, May 30, 2011 at 10:47:08AM +0200, Marc Haber wrote:
> On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> > Providing that we have consensus on a recommended strategy for
> > locking and unlocking accounts which can go into policy, I think all
> > we need are examples for h
On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.
Yes.
> However, most postinsts wrap the call to adduser with a check for
> whether the account already exists,
Which
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> 2) Reinstallation.
>
>I'm currently using this logic (in postinst)
>
> # Create dedicated sbuild user
> if ! getent passwd sbuild > /dev/null; then
> adduser --system --quiet --home /var/lib/sbuild --no-create-h
This one time, at band camp, Roger Leigh said:
> On Sun, May 29, 2011 at 12:09:40PM -0500, Jonathan Nieder wrote:
> > (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 s
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
On Sun, May 29, 2011 at 12:09:40PM -0500, Jonathan Nieder wrote:
> (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 cr
(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 Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> > Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
&g
On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > I second your original proposal though, that packages must not de
* Ian Jackson (ijack...@chiark.greenend.org.uk) [110501 16:39]:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > I second your original proposal though, that packages must n
Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > I second your original proposal though, that packages must not delete
> > system users that they have created. I don't think any
On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> I second your original proposal though, that packages must not delete
> system users that they have created. I don't think anyone had objections
> to that, and the question is whether things should be taken further.
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 th
allows system users to send messages to
connected clients via the ftpdctl program. The module works by creating a SysV
message queue, which is used to pass messages from the daemon process to
session processes.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On 12/04/11 22:43, Scott Kitterman wrote:
>> Also, we need to provide a way for sysadmin to know they can safely remove
>> a stale
>> system user.
>
> If we could do that, we could just remove them automatically and not
> bother the sysadmin.
Not necessarily. We can't be sure there aren't any fil
On ti, 2011-04-12 at 21:31 +0200, sean finney wrote:
> Hi Lars,
>
> On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
> > > But shouldn't we say they _must_ lock package-specific system users
> > > and groups when the package is removed ?
> >
> On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
>> (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,
On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
> (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 "
Hi Lars,
On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
> > But shouldn't we say they _must_ lock package-specific system users
> > and groups when the package is removed ?
>
> I think that's a good idea. Steve Langasek in the bug (#621833) and
> o
(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
gt; > >
> > > * We can decide that packages may not remove the accounts they
> > > create, ever. In that case, we should amend Policy to say this
> > > explicitly, do an MBF on the packages in the deluser.list above,
> > >
at packages may not remove the accounts they
> > create, ever. In that case, we should amend Policy to say this
> > explicitly, do an MBF on the packages in the deluser.list above,
> > and add a lintian warning against calling deluser in maintainer
> >
tion time.
>
> * We can decide that packages may not remove the accounts they
> create, ever. In that case, we should amend Policy to say this
> explicitly, do an MBF on the packages in the deluser.list above,
> and add a lintian warning against calling d
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 diff
of adduser that implements DELETE_SYSTEM_USERS.
>
> Would this be a good thing to do? Comments? Problems I've forgotten
> about?
>
> Would a debhelper tool to create/remove system users be useful? I
> suspect there's only relatively few packages that do that, so perhap
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
ncy to packages to make sure they depend on a
version of adduser that implements DELETE_SYSTEM_USERS.
Would this be a good thing to do? Comments? Problems I've forgotten
about?
Would a debhelper tool to create/remove system users be useful? I
suspect there's only relatively few pa
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
On Fri, Nov 21, 2008 at 08:18:33AM +0100, Vincent Bernat wrote:
> 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?
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
different methods.
> `
> Is it any progress on this matter? While more and more daemon become
> unprivileged or "privilege separation"-able, we get more and more system
> users.
> On some systems like OpenBSD, all those users are starting with
> und
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 ma
^used
>> Maybe it is easiest to just go with something that is popular among
>> existing packages you care about.
> On systems that I have access to, there is Debian-exim and no user
> starting with underscore. However, I have a lot of system users without
> special prefixe
fferent methods.
> `
>
> Is it any progress on this matter? While more and more daemon become
> unprivileged or "privilege separation"-able, we get more and more system
> users.
>
> On some systems like OpenBSD, all those users are starting with
> u
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
m to be as prefixes as well.
> Maybe it is easiest to just go with something that is popular among
> existing packages you care about.
On systems that I have access to, there is Debian-exim and no user
starting with underscore. However, I have a lot of system users without
special prefix
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
become
unprivileged or "privilege separation"-able, we get more and more system
users.
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 Open
Your message dated Wed, 20 Aug 2008 07:12:55 +0200
with message-id <[EMAIL PROTECTED]>
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 u
On Tue, Aug 19, 2008 at 1:21 AM, alex bodnaru <[EMAIL PROTECTED]> 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 file
Quoting alex bodnaru ([EMAIL PROTECTED]):
> 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.
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
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
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 us
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.
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
Hi,
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.
I get tons of warnings like this when I run tiger(8):
NEW: --WARN-- [pass014w] Login (bin) is disa
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
1 - 100 of 162 matches
Mail list logo
