QUESTION!: Confusing file permissions ...

QUESTION!: Confusing file permissions ...

Post by beowu » Tue, 30 Jun 1992 15:50:26



This weird thing has begun to happen to all my directories...
I get this:

drwx--S--x  4 beowulf       512 Jun 28 14:31 .
drwxr-xr-x 42 root         3072 Jun 28 23:33 ..
drwxrws---  2 beowulf       512 Jun 28 14:31 C
drwx--S---  2 beowulf       512 Jun 27 23:10 News

My question is::: WHAT THE KAKASEUFGN (Swahili) does the 'S' and 's' stand
for in the group permissions segment of file permissions?
Am I smoking crack, or is this a little weird? I'm using an athena UNIX on
sparcs...

Thanks in advance ...

Andy

 
 
 

QUESTION!: Confusing file permissions ...

Post by Michael Salm » Tue, 30 Jun 1992 18:54:25



|>
|> This weird thing has begun to happen to all my directories...
|> I get this:
|>
|> drwx--S--x  4 beowulf       512 Jun 28 14:31 .
|> drwxr-xr-x 42 root         3072 Jun 28 23:33 ..
|> drwxrws---  2 beowulf       512 Jun 28 14:31 C
|> drwx--S---  2 beowulf       512 Jun 27 23:10 News
|>
|> My question is::: WHAT THE KAKASEUFGN (Swahili) does the 'S' and 's' stand
|> for in the group permissions segment of file permissions?
|> Am I smoking crack, or is this a little weird? I'm using an athena UNIX on
|> sparcs...

From the ls man page:

     The group-execute permission character is given as s if  the
     file  has  the  set-group-id  bit  set;  likewise the owner-
     execute permission character is given as s if the  file  has
     the set-user-id bit set.

     The last character of the mode (normally x or `-') is  t  if
     the 1000 bit of the mode is on.  See chmod(1V) for the mean-
     ing of this mode.  The indications of set-ID and  1000  bits
     of  the  mode  are capitalized (S and T respectively) if the
     corresponding execute permission is not set.

man chmod gives:

     2000    Set group ID on execution (this bit  is  ignored  if
             the  file  is  a directory; it may be set or cleared
             only using symbolic mode).
     1000    Sticky bit, (see chmod(2V) for more information).

and finally man 2 chmod gives:

     If the S_ISVTX (sticky)  bit  is  set  on  a  directory,  an
     unprivileged  user  may  not delete or rename files of other
     users in that directory.

Hence the "s" means nothing and the "S" means that only you (and a
super-user) may delete files from that directory. In both cases as
no-one else has write permission this effectively means nothing as well.

--

Michael Salmon

#include        <standard.disclaimer>
#include        <witty.saying>
#include        <fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

 
 
 

QUESTION!: Confusing file permissions ...

Post by Michael Salm » Wed, 01 Jul 1992 00:02:21



[...]
|>      The last character of the mode (normally x or `-') is  t  if
|>      the 1000 bit of the mode is on.  

After a bit of experimenting I must say that this doesn't appear to be
true when a directory has the sticky bit set.

|>
[...]
|> Hence the "s" means nothing and the "S" means that only you (and a
|> super-user) may delete files from that directory. In both cases as
|> no-one else has write permission this effectively means nothing as well.

It would thus appear that both "s" and "S" mean that a directory is
sticky.

--

Michael Salmon

#include        <standard.disclaimer>
#include        <witty.saying>
#include        <fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

 
 
 

QUESTION!: Confusing file permissions ...

Post by Guy Harr » Wed, 01 Jul 1992 04:04:44


Quote:>|>      The last character of the mode (normally x or `-') is  t  if
>|>      the 1000 bit of the mode is on.  

>After a bit of experimenting I must say that this doesn't appear to be
>true when a directory has the sticky bit set.

After a trivial amount of "ls"ing I must say that it *does* appear to be
true when a directory has the sticky bit set, at least under SunOS 4.1.1
(and probably under most if not all SunOS 4.x releases):

        auspex% ls -ld /tmp
        drwxrwsrwt  3 bin          3072 Jun 29 11:56 /tmp

("/tmp" being a standard "sticky" directory in many flavors of UNIX,
including SunOS 4.1[.x]).

The original poster said he was running "Athena UNIX on SPARCs" (or an
differently-cased version of same :-)); dunno whether that means SunOS
4.x with various Project Athenaisms on top of it, or a port of, say, BSD
to the SPARC-based machines in question.

Quote:>|> Hence the "s" means nothing and the "S" means that only you (and a
>|> super-user) may delete files from that directory. In both cases as
>|> no-one else has write permission this effectively means nothing as well.

>It would thus appear that both "s" and "S" mean that a directory is
>sticky.

Nope.  "s" means that the the appropriate set-ID and execute-permission
bits are both set; "S" means that the appropriate set-ID bit is set, but
the execute-permission bit *isn't* set.

The set-UID bit on directories means nothing in SunOS 4.x (and probably
in most if not all other flavors of UNIX, either).

The set-GID bit on directories means "use BSD semantics for setting the
group of newly-created files in this directory" in SunOS 4.x (and, I
think, SVR4, and maybe some other flavors of UNIX).

Neither of them make directories "sticky" in any flavor of UNIX with
which I'm familiar; the "sticky bit" (1000 bit) is used for that in all
flavors of UNIX I know of with that notion (4.3BSD and later,
SVR3.<whatever> and later, and systems that picked it up from there,
such as SunOS 4.x and 5.x).

 
 
 

QUESTION!: Confusing file permissions ...

Post by beowu » Wed, 01 Jul 1992 13:32:22


Thanks for all the responses! But I'm still confused (no-ones fault
but my own ...) as to WHY the 's' and 'S' exist in my permissions
listing! I've had SunOS 4.1.x unix accounts for years now, and I've
NEVER encountered this. It came out of nowhere. I assume some super-user
must have placed it there, but to what end?

Oi vei. Hoy Palloi.

beowulf

 
 
 

1. File permissions/access and CHAP - confused newbie!

Greetings from a newbie Windoze refuge! (the quotations below are to keep
myself organized, I know root is root and not "root")

After much mucking around, I have a technique to log into my MCIWorld CHAP
account. They (MCIWorld) said it couldn't be done - really they said we can't
help you, go away. Anyway...

I'm trying to let the "user" fire up a ppp script rather than having to be the
"root" all the time ( a bad idea, I think) and typing in a long complicated
/usr/bin/pppd /dev/tty... command to start my ppp session. Since this is a
standalone machine and I am the only person using the machine, I think its OK
for "user" to have access to PPP. All the ideas and scripts came from
axion.physics.ubc.ca/ppp-linux.html

my users: "root" and "dave"
my scripts: pppon and chatscript (both created as "root" user with emacs)

pppon script has a line: "/usr/sbin/pppd /dev/ttyS1 .... "chat -f
$HOME/chatscript"
and chatscript dials the ISP number and sets init strings to the modem.

Now the confusion, these are the commands (from the axion paper) to let other
users (hopefully "dave") access the pppon script:

1. mv pppon /usr/bin            : worked ok, file in /usr/bin  
2. chmod a+rx /usr/bin/pppon    : worked ok too, permission changed    
3. chown <user> chatscript        :here I substituted dave for <user>, worked ok
4. su <user>                      : I did su dave
                                : I checked and chatscript
                                : has the permissions "-rw-r--r-- dave root
chatscript"
5. mv chatscript $HOME  : ERROR message
                                : mv:cannot unlink 'chatscript': permission
denied
                                : mv: cannot remove 'chatscript': permission
denied
6. chmod go-rwx $HOME/chatscript        : never got to this command!

The way I understand this stuff (not very well obviously) is that as user
"dave" I should be able to type in a terminal window "pppon" and the whole
process should start.

I'm stuck, confused and very tired (but enjoying the learning curve!). What am
I doing wrong/setting permissions wrong or ... in line 5? The $HOME shell
variable thing is representative of /home/dave/? or something like that?

Getting closer every day and TIA,
Dave

2. Partition problems with RH 4.0

3. CHAP script file permissions - confused!

4. about xxgdb debugger

5. Confused about Pine and file permissions...

6. How do I use semaphore to block POSIX threads?

7. Question about file permissions - sharing data files between multiple users

8. How to view dozens of lines of compile/link error messages?

9. - Two questions: find files with specific permission, find files that belong to..

10. Confused of Newbury, MySQL write permissions...

11. permissions, so confused

12. Confused about file access (Was: Does a file exist?)

13. How to reset permissions on file with no read permissions