FAT and exec.c (was: elksfs status)

[Mario Frasca]

Shadow Daemon wrote:

> Personally, I think it would be more to ELKS's benefit, as far as
> filesystem support goes, to concentrate on MSDOS FAT16 compatibility.

is anyone working on this?  It shouldn't be that difficult, that file system
is extremely simple and rather well documented.

As far as I could see, the only changes in the minix support from Linux to
ELKS are about loading executables (exec.c and pipe.c).  I think we can live
without that for the time being.  My question is: is it a problem, linking a
second fs type into the ELKS kernel?  or was FAT12 (and 16) not put into
ELKS just to keep it small?

By the way, I tried to modify exec.c in order to have it look at the suid
bit (I don't want to become root to run mount), but my modifications didn't
cause any change.  There is surely  a mistake, but where? :-[

here is the diff.
[mario@gunsele fs]$ cvs diff exec.c
Index: exec.c
===================================================================
RCS file: /usr/local/cvsroot/elks/fs/exec.c,v
retrieving revision 1.1.1.1
diff -U3 -b -B -r1.1.1.1 exec.c
--- exec.c      2000/01/28 22:42:51     1.1.1.1
+++ exec.c      2000/01/28 22:53:22
@@ -47,6 +47,10 @@
 char *sptr;
 int slen;              /* Size of built stack */
 {
+ /* MFr-2000-01-28 Start */
+       int suidfile, sgidfile;
+       int effuid, effgid;
+ /* MFr-2000-01-28 End */
        unsigned int result;
        int retval,execformat;
        int ds=current->t_regs.ds;
@@ -104,6 +108,15 @@
        tregs = &current->t_regs;
        tregs->ds=get_ds();
        filp->f_pos=0; /* FIXME - should call lseek */
+ /* MFr-2000-01-28
+  * can I trust the following fields?
+  */
+       suidfile = inode->i_mode & S_ISUID;
+       sgidfile = inode->i_mode & S_ISGID;
+       effuid = inode->i_uid;
+       effgid = inode->i_gid;
+ /* MFr-2000-01-28 END
+  */
        result=filp->f_op->read(inode, &file, &mh, sizeof(mh));
        tregs->ds=ds;

@@ -320,7 +333,19 @@
        current->t_inode=inode;
        arch_setup_kernel_stack(current);

+ /* MFr-2000-01-28
+  * this could be a good place to set the effective user identifier
+  * in case the suid bit of the executable had been set
+  */
+
+  if(suidfile)
+        current->uid = effuid;
+  if(sgidfile)
+        current->gid = effgid;
+ /* MFr-2000-01-28 END
+  */
        retval = 0;
+
        wake_up(&current->p_parent->child_wait);

        /*
[mario@gunsele fs]$