[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Opinions on operator's home directory?



On Thu, Jan 15, 2004 at 04:01:56PM +0000, Colin Watson wrote:

> (Please retain the Cc: to 198943@bugs.debian.org in replies.)
> 
> Bug #198943 against base-passwd comments that the operator user's home
> directory is /var, which seems to have little rationale and sometimes
> makes paths look odd in certain shells. I don't use the operator user
> for anything myself, so I'd welcome opinions on what this could sensibly
> be changed to.
> 
> 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.

I wouldn't mind if operator went away entirely; as far as I know it has no
privileges anyway.

> I looked around the BSDs, and found that FreeBSD uses / (reasonable;
> unwriteable by operator but then so is /var), NetBSD uses
> /usr/guest/operator (ugh), and OpenBSD uses /operator (perhaps
> reasonable but I'm not keen on a new top-level directory for a user many
> people never use). /home/operator isn't possible because /home may be
> NFS-mounted. /var/lib/operator, or similar? A bit ugly, and would
> require a base-files change.

Anything which is unique and likely to reside on a local disk on a diskful
machine should be fine, I would think.  Something like /var/lib/operator
would be my impulse as well.

> 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
moment).  Why not just remove it if so?  I don't think that any relevant
standard requires us to have it.

-- 
 - mdz



Reply to: