Date: Sat, 22 Apr 2000 01:07:50 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: "Artyom V. Viklenko" <artem@mipk-kspu.kharkov.ua> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Creation files & directories: which GID should be? Message-ID: <Pine.BSF.4.21.0004220048290.18268-100000@ren.sasknow.com> In-Reply-To: <390148FE.68E39232@mipk-kspu.kharkov.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Artyom V. Viklenko wrote to freebsd-questions@FreeBSD.ORG:
> Hi!
>
> I am new to FreeBSD and I have long experienc with other UNIX
> ( SCO ). Several day ago I install 3.3-RELEASE to my PC and found
> some strange situation. After loggin in as regular user (uid=200)
> I do the folowing:
>
> $ cd /tmp
> $ id
> uid=200(artem) gid=100(group) groups=100(group)
> $ > some.file
> $ ls -l
> total 0
> -rw-r--r-- 1 artem wheel 0 22 apr 09:29 some.file
> $
>
> Directory /tmp has typical mode -- no SUID, SGID flags, only sticky bit.
>
> And I'm not member of wheel group. Friens says that it is FreeBSD
> spesific.
By no means do I express to be a filesystem guru, so I can't delve into
the history or rationale of "why" it is this way from a completely
informed standpoint.
At first guess, however, I'd say it is to enforce very strict permissions
on files created in sticky directories. As an example, if a file with
default permissions of 775 (umask 002) is created with a common GID, any
group member would have access to rename or delete that file. Thus, the
files are always owned by the wheel group so only superusers or wheel
members can perform those operations. The behaviour makes sense when you
read sticky(8):
STICKY DIRECTORIES
A directory whose `sticky bit' is set becomes an append-only
directory, or, more accurately, a directory in which the deletion of
files is restricted. A file in a sticky directory may only be
removed or renamed by a user if the user has write permission for the
directory and the user is the owner of the file, the owner of the
directory, or the super-user. This feature is usefully applied to
directories such as /tmp which must be publicly writable but should
deny users the license to arbitrarily delete or rename each others'
files.
Any user may create a sticky directory. See chmod(1) for details
about modifying file modes.
You will note that the man page makes no reference to "group member" in
regards to unlinking files. Some may argue that "group member" is
implied, but, I think, given the behaviour, the current configuration is
sensible.
This might be a nitpick with freebsd-doc :-)
> But I'd like to have normal UNIX behavior with setting uid and gid in
> i-node.
> How I can fix this situtation? It sims to me, that some changes need to
> be done
> in sources of ufs filesystem...
By all means, go for it on your own system. Personally, I'm happy with
the current configuration. Perhaps others would find your patch useful,
however.
>
> Sorry for my english. Thank you!
>
>
Hope this helps,
- Ryan
--
Ryan Thompson <ryan@sasknow.com>
Systems Administrator, Accounts
Phone: +1 (306) 664-1161
SaskNow Technologies http://www.sasknow.com
#106-380 3120 8th St E Saskatoon, SK S7H 0W2
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0004220048290.18268-100000>