* [9fans] execute bits
@ 2003-06-23 18:42 Scott Schwartz
2003-06-23 19:44 ` Joel Salomon
0 siblings, 1 reply; 9+ messages in thread
From: Scott Schwartz @ 2003-06-23 18:42 UTC (permalink / raw)
To: 9fans
I recently noticed that the system is willing to run a file even if it
doesn't have the execute bits set. Did it always do that?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] execute bits
2003-06-23 18:42 [9fans] execute bits Scott Schwartz
@ 2003-06-23 19:44 ` Joel Salomon
2003-06-23 21:34 ` Kenji Arisawa
0 siblings, 1 reply; 9+ messages in thread
From: Joel Salomon @ 2003-06-23 19:44 UTC (permalink / raw)
To: 9fans
> I recently noticed that the system is willing to run a file even if it
> doesn't have the execute bits set. Did it always do that?
>
>
'disk/kfscmd allow' will do that, I've noticed.
--Joel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] execute bits
2003-06-23 19:44 ` Joel Salomon
@ 2003-06-23 21:34 ` Kenji Arisawa
2003-06-23 21:41 ` andrey mirtchovski
0 siblings, 1 reply; 9+ messages in thread
From: Kenji Arisawa @ 2003-06-23 21:34 UTC (permalink / raw)
To: 9fans
Hello,
>
>> I recently noticed that the system is willing to run a file even if it
>> doesn't have the execute bits set. Did it always do that?
>>
>>
> 'disk/kfscmd allow' will do that, I've noticed.
Yes, but that is troublesome. I think that should be fixed.
Kenji Arisawa
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] execute bits
2003-06-23 21:34 ` Kenji Arisawa
@ 2003-06-23 21:41 ` andrey mirtchovski
2003-06-23 21:53 ` Kenji Arisawa
2003-06-23 22:18 ` Scott Schwartz
0 siblings, 2 replies; 9+ messages in thread
From: andrey mirtchovski @ 2003-06-23 21:41 UTC (permalink / raw)
To: 9fans
On Tue, 24 Jun 2003, Kenji Arisawa wrote:
> Yes, but that is troublesome. I think that should be fixed.
>
the whole idea of disk/kfscmd allow is that no permission bits are checked,
including execution bits.
one should avoid having the system in an 'allowed' state as much as
possible. as I understand it, the fix is to do
disk/kfscmd disallow
:)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] execute bits
2003-06-23 21:41 ` andrey mirtchovski
@ 2003-06-23 21:53 ` Kenji Arisawa
2003-06-23 22:18 ` Scott Schwartz
1 sibling, 0 replies; 9+ messages in thread
From: Kenji Arisawa @ 2003-06-23 21:53 UTC (permalink / raw)
To: 9fans
Hello,
> the whole idea of disk/kfscmd allow is that no permission bits are
> checked,
> including execution bits.
Then
test -x file
script does not work properly. It might cause problem.
Kenji Arisawa
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] execute bits
2003-06-23 21:41 ` andrey mirtchovski
2003-06-23 21:53 ` Kenji Arisawa
@ 2003-06-23 22:18 ` Scott Schwartz
2003-06-23 22:22 ` andrey mirtchovski
2003-06-24 7:25 ` Fco.J.Ballesteros, nemo
1 sibling, 2 replies; 9+ messages in thread
From: Scott Schwartz @ 2003-06-23 22:18 UTC (permalink / raw)
To: 9fans
| one should avoid having the system in an 'allowed' state as much as
| possible.
Yes, but when a really big update is being pull-ed, it might
be in that state for a while.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] execute bits
2003-06-23 22:18 ` Scott Schwartz
@ 2003-06-23 22:22 ` andrey mirtchovski
2003-06-24 0:17 ` Kenji Arisawa
2003-06-24 7:25 ` Fco.J.Ballesteros, nemo
1 sibling, 1 reply; 9+ messages in thread
From: andrey mirtchovski @ 2003-06-23 22:22 UTC (permalink / raw)
To: 9fans
i've solved this by adding the user that does updates (i.e. me) to a special
group of users which have write permission over /src and /386...
it's a bit more complicated than that and is definitely not easier than
doing a disk/kfscmd allow, but ti avoids having the system in an unprotected
state.
the idea i got from /adm/users on sources.cs.bell-labs...
andrey
On Mon, 23 Jun 2003, Scott Schwartz wrote:
> | one should avoid having the system in an 'allowed' state as much as
> | possible.
>
> Yes, but when a really big update is being pull-ed, it might
> be in that state for a while.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] execute bits
2003-06-23 22:22 ` andrey mirtchovski
@ 2003-06-24 0:17 ` Kenji Arisawa
0 siblings, 0 replies; 9+ messages in thread
From: Kenji Arisawa @ 2003-06-24 0:17 UTC (permalink / raw)
To: 9fans
Hello,
>i've solved this by adding the user that does updates (i.e. me) to a
special
>group of users which have write permission over /src and /386...
nemo has a similar idea.
You will find in /n/sources/nemo/readme:
- change to fossil: include "fsys nnn allow -PW uid" and "who" commands.
Kenji Arisawa
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] execute bits
2003-06-23 22:18 ` Scott Schwartz
2003-06-23 22:22 ` andrey mirtchovski
@ 2003-06-24 7:25 ` Fco.J.Ballesteros, nemo
1 sibling, 0 replies; 9+ messages in thread
From: Fco.J.Ballesteros, nemo @ 2003-06-24 7:25 UTC (permalink / raw)
To: 9fans
> Yes, but when a really big update is being pull-ed, it might
> be in that state for a while.
just allow a single user instead of the whole server.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-06-24 7:25 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-23 18:42 [9fans] execute bits Scott Schwartz
2003-06-23 19:44 ` Joel Salomon
2003-06-23 21:34 ` Kenji Arisawa
2003-06-23 21:41 ` andrey mirtchovski
2003-06-23 21:53 ` Kenji Arisawa
2003-06-23 22:18 ` Scott Schwartz
2003-06-23 22:22 ` andrey mirtchovski
2003-06-24 0:17 ` Kenji Arisawa
2003-06-24 7:25 ` Fco.J.Ballesteros, nemo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).