You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Vigorito, Nicholas E." <NI...@saic.com> on 2007/08/17 21:34:01 UTC

Off-Topic - Linux questions

This is off topic but I cannot seem to find the answers to the following
for Linux. Anyone know the answers to the following:

- If the suid bit is set for the owner of a directory (looks like drws
when shown via ls -l) what does that mean? I can find what it means for
a file but not a directory.

- If the group for a directory has read/write privs but the files within
the directory have the same group but the privs on the files is just
read, can a user who is in that group remove the file from that
directory?

Thanks!

Nick

RE: Off-Topic - Linux questions

Posted by "Vigorito, Nicholas E." <NI...@saic.com>.
Thanks Chris!  

-----Original Message-----
From: users-return-167837-NICHOLAS.E.VIGORITO=saic.com@tomcat.apache.org
[mailto:users-return-167837-NICHOLAS.E.VIGORITO=saic.com@tomcat.apache.o
rg] On Behalf Of Christopher Schultz
Sent: Friday, August 17, 2007 3:52 PM
To: Tomcat Users List
Subject: Re: Off-Topic - Linux questions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vigorito,

Vigorito, Nicholas E. wrote:
> This is off topic but I cannot seem to find the answers to the 
> following for Linux. Anyone know the answers to the following:
> 
> - If the suid bit is set for the owner of a directory (looks like drws

> when shown via ls -l) what does that mean? I can find what it means 
> for a file but not a directory.

STFW: http://www.google.com/search?q=suid%20directory%20linux

Second link:
http://www.linuxforums.org/forum/linux-security/1034-suid-guid-sticky-bi
t.html

"SUID has no effect on directories, SGID on a directory makes all files
created in that directory to have the same GID as the directory itself."

Or, even, RTFM:

$ man 2 stat (on my recent Gentoo Linux system)

"The set-group-ID bit (S_ISGID) has several special uses. For a direc-
tory it indicates that BSD semantics is to be used for that directory:
files created there inherit their group ID from the directory, not from
the effective group ID of the creating process, and directories created
there will also get the S_ISGID bit set. For a file that does not have
the group execution bit (S_IXGRP) set, the set-group-ID bit indicates
mandatory file/record locking."

The S_ISUID bit has no notes, but it's purpose is to "set-user-ID on
execution". Since directories cannot be executed, there is no effect if
this bit is set on a directory.

> - If the group for a directory has read/write privs but the files 
> within the directory have the same group but the privs on the files is

> just read, can a user who is in that group remove the file from that 
> directory?

Why not just try it?

"If the group for a directory has read/write privs", "can a user who is
in that group remove the file from that directory".

Of course. The group can write to the directory. That means then can
unlink files. Remember that deleting a file on most UNIX filesystems is
just removing the entry from the directory. The filesystem determines
whether or not the actual data is worthless after the unlinking
operation.

Deleting a file to which you have no rights in a directory to which you
have full rights is always possible because the file permissions are
irrelevant: only the directory permissions are relevant.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxfxN9CaO5/Lv0PARAgK6AKCeF1A5b3QN3VKhMP8rUp8xmjObkACgmKdn
DM2r2zDy/YAs791zD4Tp0zA=
=g5q6
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Off-Topic - Linux questions

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vigorito,

Vigorito, Nicholas E. wrote:
> This is off topic but I cannot seem to find the answers to the following
> for Linux. Anyone know the answers to the following:
> 
> - If the suid bit is set for the owner of a directory (looks like drws
> when shown via ls -l) what does that mean? I can find what it means for
> a file but not a directory.

STFW: http://www.google.com/search?q=suid%20directory%20linux

Second link:
http://www.linuxforums.org/forum/linux-security/1034-suid-guid-sticky-bit.html

"SUID has no effect on directories, SGID on a directory makes all files
created in that directory to have the same GID as the directory itself."

Or, even, RTFM:

$ man 2 stat (on my recent Gentoo Linux system)

"The set-group-ID bit (S_ISGID) has several special uses. For a direc-
tory it indicates that BSD semantics is to be used for that directory:
files created there inherit their group ID from the directory, not from
the effective group ID of the creating process, and directories created
there will also get the S_ISGID bit set. For a file that does not have
the group execution bit (S_IXGRP) set, the set-group-ID bit indicates
mandatory file/record locking."

The S_ISUID bit has no notes, but it's purpose is to "set-user-ID on
execution". Since directories cannot be executed, there is no effect if
this bit is set on a directory.

> - If the group for a directory has read/write privs but the files within
> the directory have the same group but the privs on the files is just
> read, can a user who is in that group remove the file from that
> directory?

Why not just try it?

"If the group for a directory has read/write privs", "can a user who is
in that group remove the file from that directory".

Of course. The group can write to the directory. That means then can
unlink files. Remember that deleting a file on most UNIX filesystems is
just removing the entry from the directory. The filesystem determines
whether or not the actual data is worthless after the unlinking operation.

Deleting a file to which you have no rights in a directory to which you
have full rights is always possible because the file permissions are
irrelevant: only the directory permissions are relevant.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxfxN9CaO5/Lv0PARAgK6AKCeF1A5b3QN3VKhMP8rUp8xmjObkACgmKdn
DM2r2zDy/YAs791zD4Tp0zA=
=g5q6
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Off-Topic - Linux questions

Posted by Brian Munroe <br...@gmail.com>.
On 8/17/07, Vigorito, Nicholas E. <NI...@saic.com> wrote:

>
> - If the suid bit is set for the owner of a directory (looks like drws
> when shown via ls -l) what does that mean? I can find what it means for
> a file but not a directory.
>

Here is a much better explanation then I would be able to give:
http://en.wikipedia.org/wiki/Suid#setuid_on_directories

> - If the group for a directory has read/write privs but the files within
> the directory have the same group but the privs on the files is just
> read, can a user who is in that group remove the file from that
> directory?
>

If the directory has group write access then a user could remove a
file if they both have the same group membership, regardless of the
group permissions set on the file.

I would suggest some empirical testing to confirm this.

-- brian

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org