Strange messase on update

ralvez · 2008-03-07 04:03:41

I got a message after doing a pacman -Syu that reads:

(4/5) upgrading sane
warning: directory permissions differ on var/
filesystem: 755 package: 775
warning: directory permissions differ on var/lock/
filesystem: 755 package: 775

What does that mean? /var and var/lock have 755 permission and that is correct.
The directory /var/lock/sane however does have a setting of 775 and is owned by root:scanner ... is that correct?
Moreover 'sane (which seems to be the package that is complaining) has permissions set to 644 in /var/cache/pacman/pkg just like every other package and that differs from the message, that would suggest it is 775.
Am I misreading something ?

R.

Allan · 2008-03-07 04:09:30

I filed a bug report about it: http://bugs.archlinux.org/task/9778

I think /var/lock/sane is how it should be. /var and /var/lock should be 755 and don't have the right permissions in the package.

Looking at the PKGBUILD, it seems the default sane install has screwy permissions set and not all got fixed.

ralvez · 2008-03-07 04:41:20

Allan,

Thanks for the reply.
That was my feeling too ... but I did not want to be too quick to pass judgment , never a good thing.

R.

Snowman · 2008-03-07 06:21:16

According to filesystem package:
/var/ should be 755
/var/lock/ should be 1777

ralvez · 2008-03-07 13:20:20

Snowman wrote:

According to filesystem package:
/var/ should be 755
/var/lock/ should be 1777

Well... that's most interesting. My /var and /var/lock are 755 and everything seems to be working OK. I checked my main system and it is the same...
If sane has to write to this directory I understand 177... but the next 7? That means the entire world can read, write and execute on that directory and I see no need for that.
Could it be a mistake in the configuration of the package or is there any reason to set it up that way?

R.

Allan · 2008-03-07 14:01:24

It looks like /var/lock permissions have been changed to to 1777 in the filesystem package in testing. Before then it was 755. Here is why.... http://bugs.archlinux.org/task/6350

Edit: I still don't understand what was wrong with 755 there.

Last edited by Allan (2008-03-07 14:10:27)

ralvez · 2008-03-07 14:14:08

Allan,

I appreciate phracture's reasons but it does not constitute an explanation.
I would understand a 1775 but 1777 is too permissive, don't you think?
Am I being paranoid? (oh! ... what was that!! ... did you hear that noise? )

Allan · 2008-03-07 14:34:54

Well, on the non-Arch Linux machines I have access to, three have 1775 (FC3, FC5 and CentOS I think) and one has 1777 (debian?, possibly cluster-knoppix).

Well, at least with the "1" at the start there, people can't remove other users lock files. I suppose they can edit them and change the pid that is usually stored in them and cause something else to stop... Hmmm, I with you on 1775 now (but maybe it is just a bit paranoid)!

Cerebral · 2008-03-07 14:41:18

ralvez wrote:

I appreciate phracture's reasons but it does not constitute an explanation.

Just a clarification - phrakture wasn't the one who requested the change, he just replied to it:

FS Report wrote:

Opened by héctor (hacosta) - Tuesday, 06 February 2007, 00:26 GMT-4

ralvez · 2008-03-07 15:54:52

Cerebral wrote:

ralvez wrote:
I appreciate phracture's reasons but it does not constitute an explanation.
Just a clarification - phrakture wasn't the one who requested the change, he just replied to it:
FS Report wrote:
Opened by héctor (hacosta) - Tuesday, 06 February 2007, 00:26 GMT-4

Thanks Cerebral, I missed that.

R.

hacosta · 2008-03-08 20:44:12

ralvez wrote:

Allan,
I appreciate phracture's reasons but it does not constitute an explanation.
I would understand a 1775 but 1777 is too permissive, don't you think?
Am I being paranoid? (oh! ... what was that!! ... did you hear that noise? )

in that case you should check your permissions in /var/tmp

i opened the bug report a long time ago so i don't remember which other distros i used to compare or the app that expected write permissions there (perhaps a legacy app?) any way two distros that probably get this right are

debian which uses 1777
and gentoo which uses 1775(root/uucp)

dolby · 2008-03-08 21:00:28

Once again the Debian way

ralvez · 2008-03-08 22:10:10

hacosta wrote:

ralvez wrote:
Allan,
I appreciate phracture's reasons but it does not constitute an explanation.
I would understand a 1775 but 1777 is too permissive, don't you think?
Am I being paranoid? (oh! ... what was that!! ... did you hear that noise? )
in that case you should check your permissions in /var/tmp

i opened the bug report a long time ago so i don't remember which other distros i used to compare or the app that expected write permissions there (perhaps a legacy app?) any way two distros that probably get this right are
debian which uses 1777
and gentoo which uses 1775(root/uucp)

When it comes to /tmp that's fine as all file are of a temporary nature, so no big deal.
In my humble opinion Gentoo gets it right (the unix way at least )

ST.x · 2008-03-09 04:48:01

Yep im getting:

.
.
.
(1/5) upgrading filesystem                          
[####################################################################] 100%
warning: /etc/fstab installed as /etc/fstab.pacnew
warning: /etc/ld.so.conf installed as /etc/ld.so.conf.pacnew
warning: directory permissions differ on var/lock/
filesystem: 755  package: 1777
.
.
.

And ye only the var/lock/ permissions message is confusing me..

Last edited by ST.x (2008-03-09 04:49:24)

phrakture · 2008-03-10 16:38:05

The rationale is simple: /var/lock is typically used for application lock files. It makes sense that apps that require a lock file are able to write them...

ralvez · 2008-03-10 22:49:02

phrakture,

I think we all agree and understand that point. The thing that seems to be departing from reasonable is that third 7 which makes that directory world writable ... but the rest of the world does not need to have write access to that directory and therefore it should not have it. That's why I think the Gentoo approach is more sensible in therms of settings. It allows applications to do what they need to do a-la-Unix without giving overextended permissions a-la-Microsoft ... ;-)

R.

Last edited by ralvez (2008-03-10 22:50:28)

brebs · 2008-03-10 23:00:13

Hang on, what is wrong with 1777? It's the same with /tmp and /var/tmp - are you saying that /tmp is fundamentally insecure? Let's see an example.

$ ll /tmp/uPVQtzAcFj.html 
-rw------- 1 brebs brebs 0 2008-03-10 20:17 /tmp/uPVQtzAcFj.html

Only I can read or write to that file

Edit: Another test:

$ cd /var/lock
$ touch testfile
$ ll testfile
-rw-r--r-- 1 brebs brebs 0 2008-03-10 23:08 testfile

Last edited by brebs (2008-03-10 23:08:58)

ralvez · 2008-03-10 23:25:34

brebs wrote:

Hang on, what is wrong with 1777? It's the same with /tmp and /var/tmp - are you saying that /tmp is fundamentally insecure? Let's see an example.
$ ll /tmp/uPVQtzAcFj.html 
-rw------- 1 brebs brebs 0 2008-03-10 20:17 /tmp/uPVQtzAcFj.html
Only I can read or write to that file
Edit: Another test:
$ cd /var/lock
$ touch testfile
$ ll testfile
-rw-r--r-- 1 brebs brebs 0 2008-03-10 23:08 testfile

Well ... since you put it that way ... yes.
In Unix/Linux the permissions are set as Owner Group Others and the actions that can be performed in those files are 4 = Read, 2 = write, 1 =execute. Any file with the Others set to the sum of the permissions (7) can read, write and execute.
Given that fact, in the Unix world, it was traditional that you would set permissions only for the required access and if a directory does not need to be world writable it should not... and that's the sum total of what I'm saying.

A malicious user can use directories with flexible write permissions to create and write scripts or do other evil things, see?
I'm not saying it is a terrible thing and I may be a bit paranoid ... but I like the cozy feeling of a secure system. That's all.

p.s. I'm not trying to spread religion neither ... this all started as a simple question after all

brebs · 2008-03-10 23:49:44

ralvez wrote:

Any file with the Others set to the sum of the permissions (7) can read, write and execute.

Yes we know. I just showed that the permissions are more secure than that. It's 1777, not 0777. Try it and see.

With 1775, I would not be able to create a file in /var/lock/ - which presumably I should be allowed to do, yes? (It seems that hardly anything actually uses this directory.)

ralvez · 2008-03-11 00:04:23

@brebs

Actually, jut to test your idea I set my /var/lock to 1777 and this is the result:

drwxr-xr-x 2 ralvez users   4096 2008-03-09 11:24 gkrellm
drwxrwxr-x 2 root   scanner 4096 2008-03-07 01:29 sane
drwxr-xr-x 2 ralvez users   4096 2008-03-10 19:59 test
ralvez@renegade /var/lock $

See that test directory at the end? Notice the prompt ... it's me a regular user that created it.
Now with the directory set to: 1775

ralvez@renegade /var/lock $ mkdir test
mkdir: cannot create directory `test': Permission denied

... and that's when it makes you think.

brebs · 2008-03-11 00:44:42

Then don't change your umask to an insecure number.

$ grep umask /etc/profile
#Set our umask
umask 022

Edit: Oops, wrong issue. I'm confused - get to the point.

Last edited by brebs (2008-03-11 00:48:32)

Allan · 2008-03-11 01:10:29

brebs wrote:

ralvez wrote:
Any file with the Others set to the sum of the permissions (7) can read, write and execute.
Yes we know. I just showed that the permissions are more secure than that. It's 1777, not 0777. Try it and see.

I was of the impressions that the 1 meant that users could not delete a file created by another user. Can they also not edit other users files?

brebs · 2008-03-11 01:27:09

They cannot edit other users' files.

$ ls -l
total 4
drwxrwxr-x 2 root  scanner 4096 2008-03-07 06:26 sane
-rw-r--r-- 1 brebs brebs      0 2008-03-11 01:24 testfile
[ernie@brebslinux lock]$ echo "hi" >> testfile 
-bash: testfile: Permission denied

$ rm testfile 
rm: remove write-protected regular empty file `testfile'? y
rm: cannot remove `testfile': Operation not permitted

So the permissions seem to be fine.

Last edited by brebs (2008-03-11 01:28:18)

Allan · 2008-03-11 01:44:44

Doh, of course.... The directory permission just specifies who can write there and the "1" is who can remove the files within but says nothing about the permissions of the files created there! I think preventing other users removing your files is all that is needed to have /var/lock secure.

I'm still wondering what (non root use) program uses this folder and caused the bug report in the first place. I have never hit a problem with the permissions before...

ST.x · 2008-03-11 01:56:42

ok im confused about whether mine are set right now.

 [seynthantx@archstx ~]$ ll /var/lock
total 4.0K
-rw-r--r-- 1 root root 0 2008-03-10 19:21 firestarter
-rw-r--r-- 1 root root 5 2008-03-10 19:21 slim.lock

and

drwxrwxrwt  2 root root  4.0K 2008-03-10 19:21 lock

Arch Linux

#1 2008-03-07 04:03:41

Strange messase on update

#2 2008-03-07 04:09:30

Re: Strange messase on update

#3 2008-03-07 04:41:20

Re: Strange messase on update

#4 2008-03-07 06:21:16

Re: Strange messase on update

#5 2008-03-07 13:20:20

Re: Strange messase on update

#6 2008-03-07 14:01:24

Re: Strange messase on update

#7 2008-03-07 14:14:08

Re: Strange messase on update

#8 2008-03-07 14:34:54

Re: Strange messase on update

#9 2008-03-07 14:41:18

Re: Strange messase on update

#10 2008-03-07 15:54:52

Re: Strange messase on update

#11 2008-03-08 20:44:12

Re: Strange messase on update

#12 2008-03-08 21:00:28

Re: Strange messase on update

#13 2008-03-08 22:10:10

Re: Strange messase on update

#14 2008-03-09 04:48:01

Re: Strange messase on update

#15 2008-03-10 16:38:05

Re: Strange messase on update

#16 2008-03-10 22:49:02

Re: Strange messase on update

#17 2008-03-10 23:00:13

Re: Strange messase on update

#18 2008-03-10 23:25:34

Re: Strange messase on update

#19 2008-03-10 23:49:44

Re: Strange messase on update

#20 2008-03-11 00:04:23

Re: Strange messase on update

#21 2008-03-11 00:44:42

Re: Strange messase on update

#22 2008-03-11 01:10:29

Re: Strange messase on update

#23 2008-03-11 01:27:09

Re: Strange messase on update

#24 2008-03-11 01:44:44

Re: Strange messase on update

#25 2008-03-11 01:56:42

Re: Strange messase on update

Board footer