* Problem with ftw from (ice-9 ftw)
@ 2014-02-18 0:10 Frank Terbeck
2014-02-18 9:11 ` Ludovic Courtès
0 siblings, 1 reply; 4+ messages in thread
From: Frank Terbeck @ 2014-02-18 0:10 UTC (permalink / raw)
To: guile-user
Hey list,
I used to write installation routines for scheme modules in bourne
shell, that would ask the guile interpreter for (%site-path) etc.
If I call out to guile anyway, I suppose it's more natural to implement
the whole thing in scheme. That's what I did, with the help of ‘ftw’
from the (ice-9 ftw) module. That's when I stumbled across the following
odd behaviour:
Since it's an installation routine, it's likely to be called by someone
different than the owner of the directory holding the source code of a
project. The root-directory of my project has mode 0700 with a user
different from root:
[snip]
% ls -ladn .
drwx------ 11 1000 1000 4096 Feb 18 00:53 .
[snap]
In that directory and as root, I'm doing the following at guile's REPL:
[snip]
scheme@(guile-user)> (use-modules (ice-9 ftw))
scheme@(guile-user)> (format #t "UID: ~d, EUID: ~d~%" (getuid) (geteuid))
UID: 0, EUID: 0
$1 = #t
scheme@(guile-user)> (ftw "." (lambda (name stat flag)
(format #t "~s: ~s~%" name flag)))
".": directory-not-readable
$2 = #t
[snap]
The code treats root like a normal user, disregarding the fact that this
particular users will be able to access any file or directory no matter
the ownership or mode. Indeed, the ‘scandir’ routine from the same
module will read the contents of that directory just fine.
Maybe the accessibility code should be disabled when (geteuid) returns
zero?
Regards, Frank
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Problem with ftw from (ice-9 ftw)
2014-02-18 0:10 Problem with ftw from (ice-9 ftw) Frank Terbeck
@ 2014-02-18 9:11 ` Ludovic Courtès
2014-02-18 22:04 ` Frank Terbeck
0 siblings, 1 reply; 4+ messages in thread
From: Ludovic Courtès @ 2014-02-18 9:11 UTC (permalink / raw)
To: guile-user
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
Hello,
Frank Terbeck <ft@bewatermyfriend.org> skribis:
> [snip]
> % ls -ladn .
> drwx------ 11 1000 1000 4096 Feb 18 00:53 .
> [snap]
>
> In that directory and as root, I'm doing the following at guile's REPL:
>
> [snip]
> scheme@(guile-user)> (use-modules (ice-9 ftw))
> scheme@(guile-user)> (format #t "UID: ~d, EUID: ~d~%" (getuid) (geteuid))
> UID: 0, EUID: 0
> $1 = #t
> scheme@(guile-user)> (ftw "." (lambda (name stat flag)
> (format #t "~s: ~s~%" name flag)))
> ".": directory-not-readable
> $2 = #t
> [snap]
>
> The code treats root like a normal user, disregarding the fact that this
> particular users will be able to access any file or directory no matter
> the ownership or mode.
Indeed, that’s a bug. I believe this is fixed with this patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 536 bytes --]
diff --git a/module/ice-9/ftw.scm b/module/ice-9/ftw.scm
index 9c9694f..133e9c9 100644
--- a/module/ice-9/ftw.scm
+++ b/module/ice-9/ftw.scm
@@ -259,7 +259,8 @@
(let* ((perms (stat:perms s))
(perms-bit-set? (lambda (mask)
(not (= 0 (logand mask perms))))))
- (or (and (= uid (stat:uid s))
+ (or (zero? uid)
+ (and (= uid (stat:uid s))
(perms-bit-set? #o400))
(and (= gid (stat:gid s))
(perms-bit-set? #o040))
[-- Attachment #3: Type: text/plain, Size: 333 bytes --]
However, that ‘ftw’ tries to do permission checks by itself is really a
flaw in the first place, IMO.
> Indeed, the ‘scandir’ routine from the same module will read the
> contents of that directory just fine.
I would recommend using ‘scandir’ or ‘file-system-fold’ from (ice-9 ftw)
for new code.
Thanks,
Ludo’.
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: Problem with ftw from (ice-9 ftw)
2014-02-18 9:11 ` Ludovic Courtès
@ 2014-02-18 22:04 ` Frank Terbeck
2014-02-20 21:59 ` Ludovic Courtès
0 siblings, 1 reply; 4+ messages in thread
From: Frank Terbeck @ 2014-02-18 22:04 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guile-user
Ludovic Courtès wrote:
> Frank Terbeck <ft@bewatermyfriend.org> skribis:
[...]
>> The code treats root like a normal user, disregarding the fact that this
>> particular users will be able to access any file or directory no matter
>> the ownership or mode.
>
> Indeed, that’s a bug. I believe this is fixed with this patch:
[...]
Yes, that patch fixes the problem.
> However, that ‘ftw’ tries to do permission checks by itself is really a
> flaw in the first place, IMO.
Agreed.
>> Indeed, the ‘scandir’ routine from the same module will read the
>> contents of that directory just fine.
>
> I would recommend using ‘scandir’ or ‘file-system-fold’ from (ice-9 ftw)
> for new code.
Thanks. I'll probably rewrite it using ‘file-system-fold’.
Regards, Frank
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Problem with ftw from (ice-9 ftw)
2014-02-18 22:04 ` Frank Terbeck
@ 2014-02-20 21:59 ` Ludovic Courtès
0 siblings, 0 replies; 4+ messages in thread
From: Ludovic Courtès @ 2014-02-20 21:59 UTC (permalink / raw)
To: guile-user
Frank Terbeck <ft@bewatermyfriend.org> skribis:
> Ludovic Courtès wrote:
>> Frank Terbeck <ft@bewatermyfriend.org> skribis:
> [...]
>>> The code treats root like a normal user, disregarding the fact that this
>>> particular users will be able to access any file or directory no matter
>>> the ownership or mode.
>>
>> Indeed, that’s a bug. I believe this is fixed with this patch:
> [...]
>
> Yes, that patch fixes the problem.
I committed it, so it will be in 2.0.10.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-02-20 21:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-18 0:10 Problem with ftw from (ice-9 ftw) Frank Terbeck
2014-02-18 9:11 ` Ludovic Courtès
2014-02-18 22:04 ` Frank Terbeck
2014-02-20 21:59 ` Ludovic Courtès
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 read-only IMAP folder(s) and NNTP newsgroup(s).