rther 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 unshared
(or de
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 do so. Th
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/users
ay 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 c
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
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:
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.
e 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 way to refer
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
ased 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
conclusion
❦ 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,
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
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 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 for
#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 changes like
) 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 look appropriate?
[in the preinst]
-usermod -U -e '' quake-server
On Sat, 30 Jun 2012 14:36:47 +0100, Roger Leigh rle...@codelibre.net
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
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 special
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-home \
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 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 how
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 delete
system users that they have
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:
I second your original proposal
(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: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 create the
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
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.
I do object
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 anyone had objections
* 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 not delete
system users
On Thu, 31 Mar 2011 09:23:33 +0100, Lars Wirzenius l...@liw.fi 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
: The mod_msg module 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
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 ?
I think that's a good idea. Steve Langasek
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 files lying
(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 the following sentence to the end
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
others agree, so I think there's
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 UID and GID classes, the paragraph on
uids
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 UID and GID classes, the paragraph
on
uids
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 remove system users and groups they have
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
scripts.
Ian and Tollef and Scott Kitterman are against removal of system users,
and nobody (except, very mildly, me
.
Ian and Tollef and Scott Kitterman are against removal of system users,
and nobody (except, very mildly, me) is for their removal, so I guess
the consensus on -devel is clear: we should not remove system users,
ever, in maintainer scripts. If an admin wants to do it manually, that
is, of course
, 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
scripts.
Ian and Tollef and Scott Kitterman are against removal of system users,
and nobody
]] 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
Tollef Fog Heen tfh...@err.no 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
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 general
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 packages that do that, so perhaps
not.
I earlier blogged about
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
in postrm. Add a
versioned dependency 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
Hi,
On Sat, 15.11.2008 at 08:49:12 +0100, Vincent Bernat ber...@debian.org 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
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) have user
[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 characters,
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?
Yup,
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
underscore to avoid collision with real users
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
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
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 contains the
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: one
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 prefixes. Do you have some popular packages with a system user
starting with debian- in mind
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 this,
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 prefixes. Do you have some popular packages with a system user
starting with debian- in mind?
I was thinking about popular amongst
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 names
.
`
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
underscore to avoid collision with real users. On Debian, I have
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 packages
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 with
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 some
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 OpenBSD (like openntpd
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.
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 files work
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 users' homes
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 secure
in this
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 now /bin/nologin
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/false
There
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 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 explain
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 which is more secure
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.
If
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 to smuggle an
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 usually
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 it is a
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 as
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 Hermann
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
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 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 shell,
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
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
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 disabled, but has
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
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
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
on the network (using NIS or LDAP, or something
similar), you will probably break mail for people with 500 = UID
1000 if you go doing this blindly. Note that, because of the NIS/LDAP
possibility, it's not necessary that the sysadmin has reconfigured
adduser to not create system users
(or at least did when I last used it).
[...]
* 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 using the documented API.
Ok (I
1 - 100 of 160 matches
Mail list logo
