Re: concurrent users in one account

From: Floyd L. Davidson (floyd_at_barrow.com)
Date: 06/09/04


Date: Tue, 08 Jun 2004 20:13:11 -0800

efflandt@xnet.com (David Efflandt) wrote:
>On Tue, 08 Jun 2004 01:09:08 -0800, Floyd L. Davidson <floyd@barrow.com> wrote:
>> "Broetchen" <y0013515@tu-bs.de> wrote:
>>>> Yes. Re-examine your reason for not providing a user account to each of
>>>> those users.
>>>
>>>Well, the system is planned to have quite a few users logging in. Every user
>>>should have access to certain applications. I can't copy all the app data
>>>into each user account.
>>
>> Why not? The only part that needs to be copied to each account
>> is that precise part that you don't want other users to
>> write or erase.
>>
>> There are *lots* of ways to accomplish that, and which is best
>> depends greatly on what you are doing, so we can't really give
>> explicit examples without more details. However, the
>> application should not be putting common data into a user's home
>> directory... and if it is, that should to be addressed at the
>> app configuration level, not at the user configuration level.
>> And, aside from that, if you really have to share some files
>> that *must* show up in a user's home directory, you can easily
>> use symlinks to accomplish that.
>
>Symlinks will not work if they point outside of a chroot, however hard

None of what I said was meant to be used with chroot... that
was just another quirk that the OP is throwing in because he
isn't clear on how unix systems function.

>links will work if the original app files are on the same partition. What
>you end up with hard links is multiple directory entries pointing to the
>same physical file, but the links can have root ownership, with just
>execute (and read if necessary) permission for group or others.
>
>I just don't understand why some people are so intent on using chroot on a
>system designed for multiuser. I have been on a Solaris ISP since 1995
>where we have full access to the system, and the only problems we ever had
>with user accounts being hijacked was long ago when those users used an
>exploitable irc client. On another FreeBSD system I help with, the users
>have full shell access and only apache and sendmail run in a virtual jail
>(so they can have their own config files for virtual hosts).

And if full access is for whatever reason not desired (for
example, a Point Of Sale terminal), there are better ways to
restrict that access than using chroot. Basically, if the user
needs a shell, the user needs full access. If the user doesn't
need full access, the user doesn't need a shell at all.

>I was on a public system that got rooted while running Linux before some
>exploits were corrected, but they are now running NetBSD, so that is no
>longer an issue.

That is still an issue... there are rootkits for just about
anything. I've seen two systems attacked. One was running
SunOS (some years back), and the other was running BSDI (not as
many years, but not yesterday).

>File permissions allow a user to set as much access as they want to on
>their files, and it is much easier to learn about the system and help
>another user by spotting an obvious mistake, than taking many wild
>guesses.

-- 
FloydL. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com


Relevant Pages

  • Re: Only an ftp account
    ... > You may also want to add that user to /etc/ftpchroot which will chroot ... >> How would I be able to give an account to someone where they can only ... >> login and use FTP? ... Let me just point out that just changing the shell to /sbin/nologin ...
    (FreeBSD-Security)
  • Re: [fw-wiz] Best-of-breed Proxies (was Re: Proxy Firewalls ...)
    ... >> It used a chrooted sshd with private passwd/shadow files in the ... >> chroot jail. ... The login shell for the users in that private passwd ... >> config file to get a destination host, and execed an ssh client to ...
    (Firewall-Wizards)
  • Re: Restricted Shells or Menu Based Shells
    ... I am using the flash program for the users that do not require a shell. ... create a chroot area for them using the jail program. ... I am considering a virtual server scenario as a next tier. ... to the point where we break even on the hosting costs. ...
    (Focus-Linux)
  • Re: Chroot environment for ssh
    ... > would like to use SSH for the connections, as opposed to FTP, but I ... > users to be able to log into an interactive shell and I ... > want them to 'escape' out of their home directories. ... directives to chroot the groupand/or userthat are to have ...
    (FreeBSD-Security)
  • Re: Problems with Sudo
    ... Under chrootssh I wouldn't expect anything else because chroot ... non-sudo account, su to another account, and run sudo as long as that ... Any one of the three cuts brute force attacks ...
    (Ubuntu)