[EMAIL PROTECTED] wrote:
static inline int autofs4_ispending(struct dentry *dentry)
{
struct autofs_info *inf = autofs4_dentry_ino(dentry);
+int pending;
-return (dentry-d_flags DCACHE_AUTOFS_PENDING) ||
-(inf != NULL inf-flags AUTOFS_INF_EXPIRING);
The Active Block I/O Scheduling System (ABISS) is an extension of the
hard-disk storage subsystem of Linux, whose main purpose is to provide
a guaranteed reading and (eventually) writing bit rate to applications.
ABISS is conducted by Philips Research in Eindhoven, the Netherlands
(see
On Mon, 11 Apr 2005, Andrew Morton wrote:
[EMAIL PROTECTED] wrote:
static inline int autofs4_ispending(struct dentry *dentry)
{
struct autofs_info *inf = autofs4_dentry_ino(dentry);
+ int pending;
- return (dentry-d_flags DCACHE_AUTOFS_PENDING) ||
- (inf
On Mon, 11 Apr 2005, Denis Vlasenko wrote:
On Sunday 10 April 2005 16:38, [EMAIL PROTECTED] wrote:
Hi all,
Here is autofs 4.1.4.
Please find three patches attached.
Good to see your persistent in keeping your patches upto date.
I'll work through this soon as I can fix my mistakes
On Monday 11 April 2005 12:14, Ian Kent wrote:
I remember applying several of your patches to do with this some time ago.
On my development machine (an Ultra 2), the autofs daemon failed
completely when trying to log. I mailed you asking about it but received
no answer.
I decided to return
We're having a bit of a disagreement with Christoph Hellwig about the
way FUSE does (or should do) permission checking. Comments (either
way) are appreciated.
Here's my side of the story:
FUSE (filesystem in userspace) is designed to allow mounting an FS by
non-privileged users (it can also be
On Sun, 10 Apr 2005 [EMAIL PROTECTED] wrote:
Hi all,
I have updated the autofs4 kernel module build kit (kernel 2.4) and
kernel patches (2.4 and 2.6).
There were a couple of mistakes in the release.
The kernel patches have been updated as there were some obvious errors in
them.
I've uploaded
On Sun, 10 Apr 2005 [EMAIL PROTECTED] wrote:
Hi all,
Here is autofs 4.1.4.
There were a couple of mistakes in the release.
The kernel patches have been updated as there were some obvious errors in
them.
An error in patching of the Debian portion of the init script was
corrected.
I've uploaded
3) No other user should have access to files under the mount, not
even root[5]
[5] Obviously root cannot be restricted, but accidental access to
private data is still a good idea. E.g. root squashing by NFS servers
has a similar affect.
Could you explain a little more? I
== Regarding [PATCH 1/3] autofs4 - expiring filesystem from under process;
[EMAIL PROTECTED] adds:
raven autofs4-2.6.12-rc1-mm4-wait-order.patch
raven It's possible for an event wait request to arive before the event
raven requestor. If this happens the daemon never gets notified and autofs
On Mon, Apr 11, 2005 at 05:56:09PM +0200, Miklos Szeredi wrote:
3) No other user should have access to files under the mount, not
even root[5]
[5] Obviously root cannot be restricted, but accidental access to
private data is still a good idea. E.g. root squashing by NFS
Miklos Szeredi wrote:
1) User must not be able to modify files or directories in a way
which he otherwise could not do (e.g. mount a filesystem over
/bin)
2) Suid and device semantics should be disabled within the mount
3) No other user should have access to files under
On Mon, Apr 11, 2005 at 07:22:57PM +0100, Jamie Lokier wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
Seems good - but why not sticky? Mounting a user filesystem in
/tmp/user-xxx/my-mount-point seems not unreasonable - provided
Root squashing is actually a much less obnoxious restriction. It means
that local uid 0 doesn't automatically correspond to remote uid 0.
I don't agree that it's less obnoxious. Root squashing and a
restricted directory (-rwx--) would have exactly the same affect:
root is
Miklos Szeredi wrote:
That is exactly the intended effect. If I'm at my work machine (where
I'm not an admin unfortunately) and I mount my home machine with sshfs
(because FUSE is installed fortunately :), then I bloody well don't
want the sysadmin or some automated script of his to go
On Mon, Apr 11, 2005 at 09:56:29PM +0200, Miklos Szeredi wrote:
Well the sanity check on the server side is always enforced. You
can't trick sftp or ftp to not check permissions. So checking on
the client side too (where the fuse daemon is running) makes no
sense, does it?
That argument
16 matches
Mail list logo
