Re: concurrent users in one account
From: Floyd L. Davidson (floyd_at_barrow.com)
Date: Tue, 08 Jun 2004 20:13:11 -0800
firstname.lastname@example.org (David Efflandt) wrote:
>On Tue, 08 Jun 2004 01:09:08 -0800, Floyd L. Davidson <email@example.com> wrote:
>> "Broetchen" <firstname.lastname@example.org> 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
-- FloydL. Davidson <http://web.newsguy.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) email@example.com