Re: Opinions on operator's home directory?
On Thu, Jan 15, 2004 at 08:38:35AM -0800, Matt Zimmerman wrote:
> On Thu, Jan 15, 2004 at 04:01:56PM +0000, Colin Watson wrote:
> > For reference, /usr/share/doc/base-passwd/users-and-groups.txt.gz says:
> > operator
> > Operator is historically (and practically) the only "user" account
> > that can login remotely, and doesn't depend on NIS/NFS.
> > In BSD, the operator user can read and write to tapes and read from
> > disks, so that operators can perform backups. For some reason Linux
> > seems to have lost this.
Apparently, historically, operator existed only to run dumps, and was in
group root so that it could do so. operator in Debian has never been in
group root and I don't recall anyone ever complaining.
[quoting reordered slightly]
> > At the moment, I'm inclined simply to use /. I can arrange for existing
> > installations not to be changed, which would also mean that people can
> > safely change operator's home directory locally.
> Using / makes it it problematic to actually use the account for anything
> (which, as noted above, doesn't seem to be a problem in Debian at the
That I don't see; if it's only there to run dumps then it probably
doesn't need a writable home directory. Still, if it's useless ...
> Why not just remove it if so? I don't think that any relevant
> standard requires us to have it.
> I wouldn't mind if operator went away entirely; as far as I know it has no
> privileges anyway.
On Thu, Jan 15, 2004 at 08:17:34PM +0100, Marco d'Itri wrote:
> On Jan 15, Colin Watson <email@example.com> wrote:
> > Does anyone have any other opinions?
> Who cares? In a SELinux world (in the modern linux world, actually)
> this user is pointless, because we have better ways to distribute
> privileges to users. I say to just kill it.
OK, I'm persuaded. This is a last call: if you object to the operator
user no longer being in /etc/passwd on fresh installs, shout now and
give your reasons. It will not be removed from existing systems.
The operator group will remain, since it appears to be hard-coded into
dump(8) for the -n option.
Colin Watson [firstname.lastname@example.org]