Summary on Setting Permitions

From: Psarras Nikos <psarnik_at_aetos.it.teithe.gr>
Date: Thu, 08 Apr 1999 20:55:52 +0200

hi,

Original message {

  Why the /var insists to have permitions 775. We are changing it to
755 and when ever we reboot the mashine it becomes 775 all by itself!!
}

 
many thanks to
  Lars Bro
  Dr. Blinn
who applied

Lars Bro lbr_at_dksin.dk {

 hi,
 I think it is OK to have members of the system group being able to
 write to /usr/var. This is normally only administrators.
}

  NO it is not ok to leave /var with 775 permitions its a big ungly black
hole with many root shells on /tmp for public use. And not only that check
the /var/dt too to see the permitions there.

Dr. Blinn - tpb_at_doctor.zk3.dec.com {

 Look through the startup scripts in /sbin/init.d and I bet you will find at
 least one script (I'm betting on sendmail) that changes the protection on the
 /var directory at startup.
 
 I can understand why you think the mounted /var should not need group write
 permission, and you can probably figure out how to change it, but if you do
 change it, test carefully to make sure you haven't broken something that has a
 dependency on that group write permission.
 
 And, by the way, you could always create your own scripts to run at various
 points in the system's transitions from one run level to the next that can
 make such changes.
 
 Tom
}

  No its not sendmail. Sendmail does not want those permitions for /var
and much more it is not changing them.

Ok i had only those two answers and nothing else.

The hole thing started when we tried to install sendmail 8.9.3:

We first used Common Desktop Environment and we did not realize that the
/var directory had write permitions for group.

The next step was to install sendmail 8.9.3 instead of sendmail 8.8.8 that
came with the new version of osf. We did it but when we tried to start
sendmail it was refusing to rebuild the aliases file because of the group
write permition on /var. We changed the permitions on /var (chmod 755
/var) and then sendmail started up normaly without problems.

(That time we were still using CDE)

We reboot the system and in our suprize we realize that the /var directory
had AGAIN group write permitions.

The next move was to go down to single user mode change again the
permitions on /var (chmod 755 /var) and manualy start all the scripts that
/sbin/rc3 starts (multi user mode). After the end of every script we
checked the permitions on /var. The last scrpit was xlogin that is firing
up CDE (if you choose to). After that script the permitions changed
again on /var. This situation is not acceptable at all.
xlogin does not include chmod 775. I guess it is done within
/usr/dt/bin/dtlogin or something like that.

We logged on and runned xsetup to change from CDE to xdm. We changed
again the permitions on /var and we rebotted the system again. All things
about permitions on /var were ok.

Sure you can change permitions inside the S95xlogin in the last line with
chmod 755 /var or by making your own script and make it execute last but
as Dr. Blinn said "test carefully to make sure you haven't broken
something that has a dependency on that group write permission."
 
The funny thing is that i have seen the next summary :

{

>Subject: Re: Strange License Problem With XP1000 Workstations
>
> The original problem occurs because of a license bug in
> the V4.0E vmunix kernel that occurs only when xdm is the
> default window manager. This problem only exists in the
> V4.0E release. It is fixed in the V4.0E patch kit #2. That
> patch kit will be available in the May/June 1999 timeframe.
>
> In the meantime there are two possible workarounds.
>
> The first workaround is to restore cde as the default window
> manager and then select xdm for each console login. The lmf
> problem won't occur when logging-in this way. This can be done
> from the cde console login window by first selecting the "Options"
> dialog box, then selecting the "Session" dialog box, then
> selecting "Dxsession Session". Although this needs to be done
> for every login from the console, it does avoid the lmf problem
> and it doesn't use cde sessions.
>
> The second workaround is to get a temporary license pak intended
> to workaround this problem. Send mail to Joe Mario
> (mario_at_zk3.dec.com) if this special temporary pak is needed.
>
>
}

  So what are we gonna use? Is this a loop or what? Lets see for the
licencse we must use CDE and after that we must use xdm.

I hope i am absolutely wrong. If i am please inform me.

Thanks for listening again.

Take care.
salaGatoR.
Received on Thu Apr 08 1999 - 17:57:04 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:39 NZDT