Would you kill these user accounts?

[thedaver]

bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh


This server is leased. I know 'mail' isn't going to get used by my qmail kit. Are 'bin' and 'sys' holdovers from a bygone era? I'll probably check with the vendor on 'backup', but that's a traditional user also...

At the least I want to give these accounts /bin/false for a shell. Thoughts appreciated.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[RhythmAce]

I tend to agree that they may be holdovers. I just looked at RHEL5 and the only one there is mail and that has /sbin/nologin for the shell. That doesn't mean that other distros don't still use them though. I pretty much stay confined to the realm of redhat a don't venture out past centos and fedora. So if your running redhat, you can pretty much 86 those puppies. Other than that, you may want to check with someone who has done a clean install of the distro you're using. If those users are there then it's safe to assume they are needed otherwise your suspicions are correct and they are leftovers from upgrades that didn't get deleted.

 

[zeland]

I've only got bin & mail on all of my Fedora 7/8 machines with /sbin/nologin for their shells. My spare Ubuntu 7.10 desktop however, has all the exact accounts you listed. This could be a Debian thing. Maybe your server is running Ubuntu Server Ed.

--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[thedaver]

Yes, zeland, you're spot on. It's a Ubuntu server.

That's the basis for my concern. The "Debian way" has a number of pitfalls for a RH guy like me when I go and try pruning things. However, I don't think I've EVER known a system where user "sys" had a task to own.

Hopefully it doesn't own "init" ;-)

More ideas? Thanks guys!

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[Annihilannic]

'sys' sometimes owns some cron jobs, such as sar data collection.

Annihilannic.

 

[thedaver]

Anni, you'd expect to see that user assigned in the system or root crontabs, right? The user cannot be set in the job scripts themselves? Or maybe with setuid...?

Currently, I do not see 'sys' shown in the crontab job lists.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[macd68]

No. I'd deny those accounts a valid shell at best. You cause issues with future installations/updates and portability by removing legacy user accounts...unless you are really going to break with POSIX + the LSB. Also these accounts exist because there was and is a time when you want root uninvolved and that means some function spread and apparent account-sprawl, which may be distribution specific. ymmv.

 

[Annihilannic]

Anni, you'd expect to see that user assigned in the system or root crontabs, right? The user cannot be set in the job scripts themselves? Or maybe with setuid...?

I'd expect to see standard cron jobs owned by that user... but... ignore me, I must be thinking of Solaris, I checked a couple of Linux boxes and sar runs under root on those, I can't think of anything else that might use that account.

Annihilannic.

 

[stefanwagner]

Look into /etc/shadow.
It those users don't have a login-password, it should be secoure - shouldn't it?

don't visit my homepage:

http://home.arcor.de/hirnstrom/bewerbung