Re: System users: removing them

[Jonathan Nieder]

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 preinst employing this strategy.

Ah, that's the piece I had forgotten about (and I should have thought
more clearly about it; sorry about that).  Thanks for explaining.

> 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 maintainer scripts are
> expected to handle account creation and locking/unlocking.

Makes sense, of course.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529194311.GB14141@elie

Re: System users: removing them

[Jonathan Nieder]

(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 add an explict unlock/lock to the maintainer scripts,
> dropping use of deluser entirely.

The obvious question then would be whether it's worth adding special
support to deluser *and* adduser, no?

I don't have an answer in mind, though the lazy person in me would
like it to work.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529170940.GA6574@elie

Re: System users: removing them

[Marc Haber]

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 patches to adduser --system to allow it to be
used in maintainer scripts with as little wrapping code as possible
...

>I earlier blogged about an "addsysuser" tool[0], but Stephen Gran
>pointed out to me that it's mostly unnecessary scaffolding.

... which is also the cause why I don't understand why an addsysuser
tool were useful. If adduser --system needs any additional code in a
maintainer script, I'd consider that a bug in adduser which should be
filed and addressed.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qejvs-0003cs...@swivel.zugschlus.de

Re: System users: removing them

[Lars Wirzenius]

(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 of
> > the paragraph:
> > 
> > Packages must not remove system users and groups they have
> > created.
> 
> 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 a strong consensus on that.


-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1302630070.29407.16.ca...@havelock.liw.fi

Re: System users: removing them

[Ian Jackson]

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
> created.

But shouldn't we say they _must_ lock package-specific system users
and groups when the package is removed ?

In which case, we need packages to still call deluser (as most do) and
deluser to do the right thing.  I think we should sort this out before
changing policy, so we know what it is package maintainers are
supposed to do.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19874.64686.98445.806...@chiark.greenend.org.uk

Re: System users: removing them

[Lars Wirzenius]

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
> > 
> > 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 wrote:
> > > > The current default is not to delete the user because packages don't
> > > > generally do so, surely ?
> > > 
> > > I ran the attached script (same as the one I attached to my previous
> > > mail, to the bash thread) to unpack all amd64 sid/main binary packages,
> > > and then grepped for use of adduser or deluser in maintainer scripts:
> > > 
> > > find pool -name postinst -o -name preinst -o -name postrm -o
> > > -name prerm | xargs grep adduser > adduser.list
> > > 
> > > And the same, replacing adduser with deluser. The lists are a few tens
> > > of kilobytes in total, so I won't attach them to the mailing list, but
> > > I've put them on the web:
> > > 
> > > http://files.liw.fi/temp/adduser.list
> > > http://files.liw.fi/temp/deluser.list
> > > 
> > > There seem to be 106 maintainer scripts that mention deluser, in 103
> > > packages. (I did not manually verify that they're all actually calling
> > > deluser.)
> > > 
> > > 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 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
> > > scripts.
> > 
> > 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, OK.
> > 
> > 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
> > created.
> 
> This does sound like a sensible addition.  Will the packages be
> responsible for locking the accounts?
> 
> I've always found the addition and removal of user accounts in
> maintainer scripts difficult, due to the huge difference in
> practice between packages, and the lack of detailed guidance on
> best practice.  Would it be worth adding explicit examples of
> how to add system users and groups in Policy.  Also, would it
> be worth adding support to debhelper or dpkg-maintscript-helper
> to do the user addition--it would unify the process so that
> packages won't have to reinvent the wheel, and make things
> much more simple and reliable.
> 
> 
> Regards,
> Roger
> 

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1302351687.2441.80.ca...@havelock.liw.fi

Re: System users: removing them

[Roger Leigh]

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/debian-devel/2011/04/msg00210.html
> 
> On ma, 2011-04-04 at 21:09 +0100, Lars Wirzenius wrote:
> > > The current default is not to delete the user because packages don't
> > > generally do so, surely ?
> > 
> > I ran the attached script (same as the one I attached to my previous
> > mail, to the bash thread) to unpack all amd64 sid/main binary packages,
> > and then grepped for use of adduser or deluser in maintainer scripts:
> > 
> > find pool -name postinst -o -name preinst -o -name postrm -o
> > -name prerm | xargs grep adduser > adduser.list
> > 
> > And the same, replacing adduser with deluser. The lists are a few tens
> > of kilobytes in total, so I won't attach them to the mailing list, but
> > I've put them on the web:
> > 
> > http://files.liw.fi/temp/adduser.list
> > http://files.liw.fi/temp/deluser.list
> > 
> > There seem to be 106 maintainer scripts that mention deluser, in 103
> > packages. (I did not manually verify that they're all actually calling
> > deluser.)
> > 
> > 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 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
> > scripts.
> 
> 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, OK.
> 
> 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
> created.

This does sound like a sensible addition.  Will the packages be
responsible for locking the accounts?

I've always found the addition and removal of user accounts in
maintainer scripts difficult, due to the huge difference in
practice between packages, and the lack of detailed guidance on
best practice.  Would it be worth adding explicit examples of
how to add system users and groups in Policy.  Also, would it
be worth adding support to debhelper or dpkg-maintscript-helper
to do the user addition--it would unify the process so that
packages won't have to reinvent the wheel, and make things
much more simple and reliable.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: System users: removing them

[Lars Wirzenius]

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 wrote:
> > The current default is not to delete the user because packages don't
> > generally do so, surely ?
> 
> I ran the attached script (same as the one I attached to my previous
> mail, to the bash thread) to unpack all amd64 sid/main binary packages,
> and then grepped for use of adduser or deluser in maintainer scripts:
> 
> find pool -name postinst -o -name preinst -o -name postrm -o
> -name prerm | xargs grep adduser > adduser.list
> 
> And the same, replacing adduser with deluser. The lists are a few tens
> of kilobytes in total, so I won't attach them to the mailing list, but
> I've put them on the web:
> 
> http://files.liw.fi/temp/adduser.list
> http://files.liw.fi/temp/deluser.list
> 
> There seem to be 106 maintainer scripts that mention deluser, in 103
> packages. (I did not manually verify that they're all actually calling
> deluser.)
> 
> 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 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
> scripts.

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, OK.

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
created.

Not sure if a mass bug filing is warranted if this policy change is
accepted, but definitely a lintian check would be in order (I'm happy to
write it).

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1302338668.2441.60.ca...@havelock.liw.fi

Re: System users: removing them

[Russ Allbery]

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
sure be nice.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762qtdwdq@windlord.stanford.edu

Re: System users: removing them

[Tollef Fog Heen]

]] 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 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
| scripts.

I think never deleting is the most sensible solution, the reasoning
being:

- UIDs are a cheap resource (we can use 32 bit uids nowadays), the
  overhead in /etc/passwd and friends is neglible.
- 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?
- The possible downside of reusing a UID is real.
- Giving the admin a way to set policy to delete users means we have
  more code paths to test, meaning the likehood of bugs popping up
  increases.

The same argument applies for system gids and groups, btw.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbad2ogg@qurzaw.varnish-software.com

Re: System users: removing them

[Lars Wirzenius]

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 case, but for most systems it is easy: users
and uids on my laptop, for example, are not shared elsewhere. I expect
most systems to be like my laptop.

There are systems where they leak, and where removing a user is more
difficult. That's why I would like to make it configurable by the admin.

> >   * Extra accounts are just wasteful, and may cause some confusion.
> >   * There is a tiny risk of having unused accounts on the system.
> > (We have tens of them anyway, but still.)
> 
> I think a disabled account present in passwd (with changed home
> directory, and starred out shadow entry) is less risk than a reused
> uid.

Since I don't see any problem in removing unused accounts on my laptop,
I judge the risks differently from you.

However, the risk of an unused and properly locked down account is low
enough that I am happy to live with un-purged package specific system
accounts if that's what we decide to have.

> The current default is not to delete the user because packages don't
> generally do so, surely ?

I ran the attached script (same as the one I attached to my previous
mail, to the bash thread) to unpack all amd64 sid/main binary packages,
and then grepped for use of adduser or deluser in maintainer scripts:

find pool -name postinst -o -name preinst -o -name postrm -o
-name prerm | xargs grep adduser > adduser.list

And the same, replacing adduser with deluser. The lists are a few tens
of kilobytes in total, so I won't attach them to the mailing list, but
I've put them on the web:

http://files.liw.fi/temp/adduser.list
http://files.liw.fi/temp/deluser.list

There seem to be 106 maintainer scripts that mention deluser, in 103
packages. (I did not manually verify that they're all actually calling
deluser.)

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 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
scripts.
  * We can decide to have deluser read a config setting when
removing system accounts (my earlier proposal). This would allow
a little bit of de-cluttering, but perhaps not enough to warrant
the complexity.
  * We can't decide, of course, that packages must always remove the
accounts they create, because the uid re-use and leaking
problems are real.

Did I miss an option? What do others think? What's the sensible thing to
do here?

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


unpack-debian-binaries
Description: application/shellscript

Re: System users: removing them

[Scott Kitterman]

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.
> 
>   * The user might be administered centrally, via LDAP. (So postinst
> never actually created it, and thus postrm shouldn't remove it.)
>   * There might be files owned by the user that the package does not
> know about.
>   * There might be other site policies about this.
> 
> The easy solution for this would be to never remove the user, but that's
> also not so clear.
> 
>   * Extra accounts are just wasteful, and may cause some confusion.
>   * There is a tiny risk of having unused accounts on the system.
> (We have tens of them anyway, but still.)
> 
> Most hosts, however, can safely remove the system user when the package
> is removed, if the user is to be removed at all. There may be cases
> where a package's system user should not be removed, because some files
> that belong to it will not be removed, such as a Usenet spool.
> 
> I propose the following:
> 
>   * We patch deluser to check for a boolean DELETE_SYSTEM_USERS
> setting in /etc/adduser.conf. If set to false, it does not
> remove the user. Default the setting to true, since that is
> status quo and works for most hosts and sites. Maybe also add a
> --force option to override the config file setting?
>   * Review all packages and their use of adduser/deluser. Make sure
> that they don't have unnecessary scaffolding ("if ! getenet
> passwd ..."), since it's unnecessary, and also not needed. Make
> sure they have the appropriate call to deluser 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
> suspect there's only relatively few packages that do that, so perhaps
> not.
> 
> I earlier blogged about an "addsysuser" tool[0], but Stephen Gran
> pointed out to me that it's mostly unnecessary scaffolding. In my blog
> post I also outlined a way for packages to share a system user, without
> having to depend on it, but I think that's not so useful, so I don't
> include it in this proposal.
> 
> [0] http://blog.liw.fi/posts/addsysuser/
> [1] http://i.imgur.com/3XuAi.jpg (gratuitous cat picture; NSFW language)

It seems to me that there is not a clear statement about removing users on 
purge in policy.  I'd prefer we get consensus around the policy before diving 
into implementation on this.

Personally I think the risks associated with removal are greater than the 
potential benefits and, except in unusual cases, they should be left.  I've 
got one bug open against one of my packages that I'd love to be able to close 
with "No, policy says X and so the current behavior is correct."  I'm willing 
to accept it the project decides I'm wrong, but I'd like to see a clear 
statement on what the right thing to do is.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103311129.38869.deb...@kitterman.com

Re: System users: removing them

[Ian Jackson]

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.
>   * There is a tiny risk of having unused accounts on the system.
> (We have tens of them anyway, but still.)

I think a disabled account present in passwd (with changed home
directory, and starred out shadow entry) is less risk than a reused
uid.

> Most hosts, however, can safely remove the system user when the package
> is removed, if the user is to be removed at all. There may be cases
> where a package's system user should not be removed, because some files
> that belong to it will not be removed, such as a Usenet spool.

IMO the accounts should be retained but disabled.

> I propose the following:
> 
>   * We patch deluser to check for a boolean DELETE_SYSTEM_USERS
> setting in /etc/adduser.conf. If set to false, it does not
> remove the user. Default the setting to true, since that is
> status quo and works for most hosts and sites. Maybe also add a
> --force option to override the config file setting?

The current default is not to delete the user because packages don't
generally do so, surely ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19860.32563.116133.70...@chiark.greenend.org.uk

Re: system users

[Toni Mueller]

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 uses "ntpd"). Is there some drawbacks with underscore?

none that I'm aware of.

I dimly remember having read that some (all?) authentication methods
available to users don't accept names with underscores, so the only
ways to assume such a UID would be to call "setuid(number)" and
"seteuid(number)", which would be a good thing, too.


Kind regards,
--Toni++


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: system users

[Guido Günther]

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 name limits.  For ps
> and top, it seem to be the POSIX limit of 8 characters, while
> wtmp/utmp have 32 characters as the limit (see
> /usr/include/bits/utmp.h).  To avoid admins being surprised when using
> ps and top, I would strongly recommend to avoid more than 8 characters
> in usernames.
This unfortunately doesn't match reality. Often you can't even control
how long the usernames might be if you're importing users from other
systems ldap. Not being able to see the full username (at least up to
UT_NAMESIZE, #367428) simply doesn't help and is just an anachronism.
Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: system users

[Petter Reinholdtsen]

[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, while
wtmp/utmp have 32 characters as the limit (see
/usr/include/bits/utmp.h).  To avoid admins being surprised when using
ps and top, I would strongly recommend to avoid more than 8 characters
in usernames.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: system users

[Tobi]

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]

Re: system users

[Sven Joachim]

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

   - xfs: debian-xfs

> The list was built by hand. I hope to have not forgotten anything.

At least the three above are missing.

Sven


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: system users

[Vincent Bernat]

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 bad user found in front of screen


pgp6OflkKoWdP.pgp
Description: PGP signature

Re: system users

[Vincent Bernat]

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 maintainer scripts of main/i386, though.

Thanks for the tips!

Here is  the list of  package that  name the user  with the name  of the
source package:
 - ajaxterm: ajaxterm
 - approx: approx
 - apt-cacher-ng: apt-cacher-ng
 - asterisk: asterisk
 - backuppc: backuppc
 - bip: bip
 - blootbot: blootbot
 - citadel: citadel
 - clamsmtp: clamsmtp
 - cntlm: cntlm
 - dansguardian: dansguardian
 - debarchiver: debarchiver
 - dnsmasq: dnsmasq
 - docvert: docvert
 - dovecot: dovecot
 - ejabberd: ejabberd
 - email-reminder: email-reminder
 - fcron: fcron
 - fetchmail: fetchmail
 - freevo: freevo
 - gdm: gdm
 - gkrellmd: gkrellmd
 - gnugk: gnugk
 - greylistd: greylistd
 - hobbit: hobbit
 - hplip: hplip
 - interchange: interchange
 - iodine: iodine
 - jffnms: jffnms
 - liquidsoap: liquidsoap
 - maradns: maradns
 - mldonkey: mldonkey
 - motion: motion
 - mpd: mpd
 - mpdscribble: mpdscribble
 - mt-daapd: mt-daapd
 - munin: munin
 - netmrg: netmrg
 - netplan: netplan
 - pdnsd: pdnsd
 - postgrey: postgrey
 - prayer: prayer
 - proftpd: proftpd
 - pyaimt: pyaimt
 - rancid: rancid
 - sbnc: sbnc
 - slidentd: slidentd
 - smtpguard: smtpguard
 - spampd: spampd
 - spong: spong
 - stunnel4: stunnel4
 - sympa: sympa
 - varnish: varnish
 - vdradmin-am: vdradmin-am
 - zabbix: zabbix

The packages  that use a different  name but with no  apparent prefix or
suffix (maybe gforge should not be in this category) :
 - vde2: vde2-net
 - ez-ipupdate: ez-ipupd
 - postfwd: postfw
 - kolabd: kolab
 - openntpd: ntpd
 - tinyerp-server: terp
 - policyd-weight: polw
 - zope-common: zopeuser
 - postgresql-common: postgres
 - pymilter: spf-milter-python
 - nfs-utils: statd
 - nss-ldapd: nslcd
 - net-snmp: snmp
 - gforge: anonscm-gforge scm-gforge www-gforge
 - hylafax: faxmaster
 - hal: haldaemon
 - dbus: messagebud
 - boxbackup: bbstored
 - calendarserver: caldavd
 - dtc-xen: dtc-xen-user
 - tomcat5.5: tomcat55
 - ident2: identd
 - batv-milter: batv-filter
 - nagios3: nagios
 - lastfmsubmitd: lastfm
 - gsmlib: gsmsms
 - mumble: mumble-server
 - openssh: sshd
 - fsp: ftp
 - vsftpd: ftp
 - bind9: bind
 - amavisd-new: amavis
 
And the ones that uses a prefix:
 - exim4: Debian-exim
 - lldpd: _lldpd

The list was built by hand. I hope to have not forgotten anything.

Some random remarks:
 - nobody uses prefixes
 - there are collisions (fsp, vsftpd)
 - some  names collides with  real user names  that I have  met (iodine,
   spong, prayer), this may vary from systems to systems but there is no
   way to override a username

BTW, the problem is similar with groups, especially since the default is
now to create a group for each user.
-- 
I AM NOT THE NEW DALAI LAMA
I AM NOT THE NEW DALAI LAMA
I AM NOT THE NEW DALAI LAMA
-+- Bart Simpson on chalkboard in episode 5F17


pgpr8mykjzhx0.pgp
Description: PGP signature

Re: system users

[Raphael Geissert]

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 to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: system users

[Stephen Gran]

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 will be migrating existing user setups to a new username (I
personally don't think it would be worth the pain, but YMMV).
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: system users

[Vincent Bernat]

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 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. On  Debian, I have never
> seen  this, even  for packages  that comes  from OpenBSD  (like openntpd
> which uses "ntpd"). Is there some drawbacks with underscore?

I wanted  to file a  wishlist bug against  policy about this  matter but
there is already one that exists:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248809

The bug  is pretty old and the  discussion stopped a few  years ago. The
problem of  too long usernames  when using "Debian-" prefix  was already
mentioned.

The  possibility   to  use  "_${package}"   is  mentioned  once   as  an
example.

IMO, there are three advantages to using underscore:
 - it defines a namespace (like using "Debian-" prefix)
 - the name is kept short
 - it is easy to spot those system names in ps or other tools

Is there some  way to easily retrieve all postinst  scripts to check how
adduser is called?
-- 
printk("autofs: Out of inode numbers -- what the heck did you do??\n"); 
2.0.38 /usr/src/linux/fs/autofs/root.c


pgp1JnJ5oFNvI.pgp
Description: PGP signature

Re: system users

[Vincent Bernat]

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  that comes  from OpenBSD  (like openntpd
>> which uses "ntpd"). Is there some drawbacks with underscore?

> 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.
-- 
BOFH excuse #258:
That's easy to fix, but I can't be bothered.


pgpyDabZC0HMT.pgp
Description: PGP signature

Re: system users

[Sven Joachim]

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 for real users less likely.

Sven


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: system users

[Thomas Viehmann]

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 underscore?

>> This has been discussed a couple of times, but IIRC without definitive
>> conclusion. "Debian-" and "debian-" seem to be as prefixes as well.
 ^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 prefixes.  Do you have  some popular packages with a system user
> starting with "debian-" in mind?

I was thinking about popular amongst Debian packages, not in popular
packages... tor has "debian-".

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: system users

[Osamu Aoki]

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.
> `
> 
> 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 never
> seen  this, even  for packages  that comes  from OpenBSD  (like openntpd
> which uses "ntpd"). Is there some drawbacks with underscore?

That is nice.  We will be able to get reasonable output under ps command
for exim4 too.

Osamu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: system users

[Vincent Bernat]

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, even  for packages  that comes  from OpenBSD  (like openntpd
>> which uses "ntpd"). Is there some drawbacks with underscore?

> None.  In fact, is a damn good solution to the problem.

Unfortunately,  by  default,  NAME_REGEX  does  not  allow  the  use  of
underscore. The user needs to be created with --force-badname.
-- 
No fortunes found


pgphG7bOZwpu6.pgp
Description: PGP signature

Re: system users

[Vincent Bernat]

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 packages  that comes  from OpenBSD  (like openntpd
>> which uses "ntpd"). Is there some drawbacks with underscore?

> This has been discussed a couple of times, but IIRC without definitive
> conclusion. "Debian-" and "debian-" seem 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 prefixes.  Do you have  some popular packages with a system user
starting with "debian-" in mind?
-- 
No fortunes found


pgpAfkITl96kC.pgp
Description: PGP signature

Re: system users

[Henrique de Moraes Holschuh]

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 drawbacks with underscore?

None.  In fact, is a damn good solution to the problem.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: system users

[Thomas Viehmann]

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 underscore?

This has been discussed a couple of times, but IIRC without definitive
conclusion. "Debian-" and "debian-" seem to be as prefixes as well.
Maybe it is easiest to just go with something that is popular among
existing packages you care about.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Jari Aalto]

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 context.

The /bin/nologin records the user who tried to log in. This helps
auditing the system and provides more secure approach to system
monitoring.

/bin/nologin is straight replacement of /bin/false. It originates
from BSD systems.

Jari



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Manoj Srivastava]

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 which is more secure
>
> You can surely explain why /bin/nologin is more secure than
> /bin/false. I'm eager to learn.

Since /bin/nologin is used in very specific circumstances, I
 can create far tighter security policy and auditing rules for use
 with /bin/nologin. /bin/false is used legitimately in scripts, so the
 audit trail is diffused, and /dev/null can't be restricted/audited to
 the same extent that either /bin/false or /bin/nologin can.

manoj
-- 
"The only difference between me and a madman is that I'm not mad."
Salvador Dali
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Javier Fernández-Sanguino Peña]

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

Re: System users and valid shells...

[Javier Fernández-Sanguino Peña]

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 is now /bin/nologin which is more secure
> 
> You can surely explain why /bin/nologin is more secure than
> /bin/false. I'm eager to learn.

Not "more secure" but it definately provides some accountability (i.e. log
traces) in case those accounts get used. At least by those services that
might spawn a shell, that is. Use of /dev/null or /bin/false will not get
logged so you might not be able to detect (through a logchecker tool such as
logcheck) suspicious activity.

Regards

Javier


signature.asc
Description: Digital signature

Re: System users and valid shells...

[Gabor Gombas]

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 root so a simple bug is
much more likely to become a security problem.

> Do you also expect this is more likely than an exploitable bug in
> /usr/sbin/nologin or /bin/false with their dependencies on ldso and
> glibc?

The code of nologin or false should be trivial. Spotting a place in some
complicated daemon where it fails to handle the "execve() returs an
error" case properly is much harder.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Thiemo Seufer]

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 failure path that
> is usually not well-tested. Triggering it deliberately without a general
> audit of login shell handling therefore may discover new bugs with
> security implications.

So you expect systems to become exploitable by mounting /usr as noexec
when they provide some /usr/bin/foo shell?

Do you also expect this is more likely than an exploitable bug in
/usr/sbin/nologin or /bin/false with their dependencies on ldso and
glibc?


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Gabor Gombas]

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 not well-tested. Triggering it deliberately without a general
audit of login shell handling therefore may discover new bugs with
security implications.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Thiemo Seufer]

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 infected binary into.
> 
> If the attacker has enough privileges to replace /bin/nologin or
> /bin/false, then I fail to see what extra protection would /dev/null
> give.

s/smuggle an infected/install a broken/ , doesn't change the point
I wanted to make.

> Also, applications expecting an executable binary as the login shell may
> break when they find a device node there. And if the breakage is
> exploitable, then using /dev/null may turn out to be less secure than
> using /bin/bash.

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.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Gabor Gombas]

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 the attacker has enough privileges to replace /bin/nologin or
/bin/false, then I fail to see what extra protection would /dev/null
give.

Also, applications expecting an executable binary as the login shell may
break when they find a device node there. And if the breakage is
exploitable, then using /dev/null may turn out to be less secure than
using /bin/bash.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Thiemo Seufer]

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
> 
> 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.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Marc Haber]

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 why /bin/nologin is more secure than
/bin/false. I'm eager to learn.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: System users and valid shells...

[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 on one of my
machines, and I'll create a comparison of user accounts and valid/nonvalid
shells in other distributions... This will probably take a few days, but
I'll post the results here when I'm done...

Or does such a thing already exist?


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org


signature.asc
Description: Digital signature

Re: System users and valid shells...

[Uwe Hermann]

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 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org


signature.asc
Description: Digital signature

Re: System users and valid shells...

[Jari Aalto]

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". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Nicolas François]

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 UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Javier Fernández-Sanguino Peña]

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 the recommended practice for disabling users (per
CERT's http://www.cert.org/tech_tips/unix_configuration_guidelines.html).
This is recommended because even if a user has a disabled password some
(network) services might allow remote login under certain circumstances.

In any case, and this is Debian-specific, you might want to read through
the following discussions:
http://lists.debian.org/debian-security/2003/10/msg00135.html
and 
http://lists.debian.org/debian-devel/1998/07/msg03281.html
(continued in http://lists.debian.org/debian-devel/1998/08/msg00084.html)
(1998! gasp!) for insightful comments for (some even against) this practice.

In any case, you could use noshell (already available in Debian) or nologin
(see #298782) instead of /bin/false. Those will provide also logging
capabilities (i.e. when somebody tries to use the shell this is noted in
syslog). That helps detect misuse and also detect which users *do* need a
shell for some reason (as they would trigger the log messages and you are
reviewing the logs, aren't you? :-)

Regards

Javier


signature.asc
Description: Digital signature

Re: System users and valid shells...

[Marco d'Itri]

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, all others should get /bin/false, right?
Security-wise it's probably not relevant.
Admin-wise, having a valid shell helps when using su(8).

> Should I CC debian-security?
No.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: System users and valid shells...

[Richard A Nelson]

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 same thoughts when I first installed tiger


This is bug #330882, and is basically because I'm exceptionally
conservative when it comes to base-passwd and it's rather hard to tell
whether anything in Debian might be relying on any of those users having
a valid shell.


I worried about that as well


I'm willing to change these, but I'd like to do it on a case-by-case
basis after scanning the archive for potential problems. At the moment
I'm not even sure how to begin that scan ...


As as a small datapoint, I took 4 machines I could play with and just
fixed all the IDs tiger bitched about - and waited for the fallout.

The results so far (several months later):
* fetchmail needs a shell (likely because of my pam.d & auth)
* news needs a shell to do any maintenance
* uucp needs a shell

The rest of the system accounts are happily running with /bin/false

I'm sure a few more folk could do likewise, and with some tracking,
this should be fairly easy to nail down...  With more testers, the
faster we'd find the few exceptions.
--
Rick Nelson
"By golly, I'm beginning to think Linux really *is* the best thing since
sliced bread."
(By Vance Petree, Virginia Power)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Colin Watson]

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 exceptionally
conservative when it comes to base-passwd and it's rather hard to tell
whether anything in Debian might be relying on any of those users having
a valid shell.

I'm willing to change these, but I'd like to do it on a case-by-case
basis after scanning the archive for potential problems. At the moment
I'm not even sure how to begin that scan ...

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Adam Borowski]

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 probably in every spammers list
of dictionary words to try.

Still, though, even if I'd never expect legitimate mail to e.g. my
proftpd user, I'd certainly not want to automatically discard it.  I'd
prefer a default configuration that sent it to root, but that could
easily be overridden.


What you really want, is accepting all locally-generated mail to that 
user, and rejecting/discarding everything from the outside.  However, 
there is a problem with what "outside" means.


Usually, that's just everything but localhost, but if smarthosts with no 
local mail are involved, things get messy.


--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Noah Meyerhans]

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 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 probably in every spammers list
of dictionary words to try.

Still, though, even if I'd never expect legitimate mail to e.g. my
proftpd user, I'd certainly not want to automatically discard it.  I'd
prefer a default configuration that sent it to root, but that could
easily be overridden.

noah



signature.asc
Description: Digital signature

Re: System users that receive mail in /var/mail/systemuser?

[Stephen Samuel]

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 package /user doesn't affirmatively indicate that it should never 
create/accept email, then the mail
should go through the normal email pathways. I'm a bit of a data-packrat 
and consider data loss to be a bad thing. If I want to toss those 
emails, I'll create a cron job to do it on a regular basis.


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.


Wouter Verhelst 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.


Maybe not *packages*, but possibly non-Debian software.
  

non-Debian software, running in the Debian system-user id range?



* Some other distributions (I believe RedHat is one of them, but am not
  sure) have their user UID range start at 500 rather than 1000. If
  someone is using Debian in a hybrid environment where the usernames
  are centralized on the network (using NIS or LDAP, or something
  


--
Stephen Samuel +1(778)861-7641 [EMAIL PROTECTED]
   http://www.bcgreen.com/
  Powerful committed communication. Transformation touching
the jewel within each person and bringing it to light.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Gabor Gombas]

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 using the documented API.

Yep, we're doing that here, and those usesrs should definitely receive
e-mail. Most of the time the mail is redirected using .forward but not
always, but in all cases it must be configurable at the user level
without any extra privileges, so playing with /etc/aliases is out of
question.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Andreas Metzler]

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.

>>> Maybe not *packages*, but possibly non-Debian software.

>> non-Debian software, running in the Debian system-user id range?

> * Some other distributions (I believe RedHat is one of them, but am not
>  sure) have their user UID range start at 500 rather than 1000.
[breakage with NIS or LDAP]

Yes, indeed RedHat does (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 doubt though that *these* system w/should receive mail in
/var/mail/, too.)

thanks, cu andreas
  
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Wouter Verhelst]

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 software.
> 
> non-Debian software, running in the Debian system-user id range?

* Some other distributions (I believe RedHat is one of them, but am not
  sure) have their user UID range start at 500 rather than 1000. If
  someone is using Debian in a hybrid environment where the usernames
  are centralized 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 in the 500-1000 range, so checking
  for that isn't necessarily going to work.
* 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.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Christoph Berg]

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 get mail, mail should either be blocked or
redirected to root. Currently it just rots in /var/mail/.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: System users that receive mail in /var/mail/systemuser?

[Ron Johnson]

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 software.
> 
> non-Debian software, running in the Debian system-user id range?

I'm sure there are some closed-source apps out there that try to
create account(s) with uid < 1000.  That's why I wonder whether
"rejected immediately" is the wise path.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

Under capitalism man exploits man. Under communism it's the other
way around.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Andreas Metzler]

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'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.

> So unless I'm wrong here, a general mechanism to redirect/reject mail
> to such users should be invented. Maybe adduser could do that?

Policy 11.6. "/etc/aliases is the source file for the system mail
aliases (e.g., postmaster, usenet, etc.), it is the one which the
sysadmin and postinst scripts may edit."

And indeed e.g. clamav or inn2 will add itself to it (if it exists.)
   cu andreas
/etc/aliases.

-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Andreas Metzler]

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?
  cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Christoph Berg]

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 users into
/etc/aliases, and in fact, my sid chroot doesn't even have that file.

So unless I'm wrong here, a general mechanism to redirect/reject mail
to such users should be invented. Maybe adduser could do that?

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: System users that receive mail in /var/mail/systemuser?

[Ron Johnson]

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 real user by /etc/aliases.
> 
> >> I do wonder whether it would be safe to reject any mail for
> >> system-accounts (uid <1000 || uid >63434) unless it is redirected with
> >> /etc/aliases?
> >> cu andreas
> 
> > Or just redirect all such mail to root, that way you don't have to keep 
> > /etc/aliases up to date for every package installed that creates a user.
> 
> Hello,
> looks like I was unclear. I wanted to change current semi-policy:
> 
> #1 sane packages redirect mail via /etc/aliases
> #2 insane packages park it in /var/mail/systemuser, where nobody will
>see it
> #3 insane packages probably do not exist, /var/mail/systemuser
>probably just contains spam
> 
> to
> #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).
> 
> And now I am wondering whether this will break existing packages.

Maybe not *packages*, but possibly non-Debian software.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

"You know your children are growing up when they stop asking you
where they came from and refuse to tell you where they're going."
P.J. O'Rourke, satirist


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Andreas Metzler]

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 to reject any mail for
>> system-accounts (uid <1000 || uid >63434) unless it is redirected with
>> /etc/aliases?
>> cu andreas

> Or just redirect all such mail to root, that way you don't have to keep 
> /etc/aliases up to date for every package installed that creates a user.

Hello,
looks like I was unclear. I wanted to change current semi-policy:

#1 sane packages redirect mail via /etc/aliases
#2 insane packages park it in /var/mail/systemuser, where nobody will
   see it
#3 insane packages probably do not exist, /var/mail/systemuser
   probably just contains spam

to
#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).

And now I am wondering whether this will break existing packages.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users that receive mail in /var/mail/systemuser?

[Sam Morris]

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 || uid >63434) unless it is redirected with
/etc/aliases?
cu andreas


Or just redirect all such mail to root, that way you don't have to keep 
/etc/aliases up to date for every package installed that creates a user.


--
Sam Morris
http://robots.org.uk/

PGP key id 5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]